Hey - Everything I read about all the types of 'recordsets' in ADO.NET says *be carefull* because they all 'lock' the connection object so that no other datareaders/sets can use it until it is released.<BR><BR>Am I misinterpretting something or is this really true? Are there any record fetching objects I *can* use that won't lock the connection to only itself? My current solution is to just use plain old adodb. 
<BR><BR>ChrisHere is what I think they mean by that. You can only have one open server-side recordset at a time per connection object. This has been true even in the older ADO. This doesn't mean that only one person using your site can access the database at one time. If another person comes along and wants to connect and the connection is busy, the server will open up a new one. This is called connection pooling and is done for you automaticly. <BR><BR>I think there are a couple of reasons why they might stress this more with .net. One reason is because .net is much more easily multi-threaded, there is a greater chance of accidentily using a busy connection object to run a query. Another that is more important to ASP.net is that the connection object should always be explicitly closed for every page. ASP.net's garbage collection takes alot longer to clean up a forgotten connection object than ASP would.<BR><BR>One of the best ways to avoid locking a connection would be to use DataAdapters to fill DataSets rather than using DataReaders. They will run and finish up the query right away, but use more web server memory to hold the results (like disconnected recordsets in ADODB). As long as your page opens up its own connection object for its data, and closes it when its done, there really isn't anything to worry about.Thanks for the info... So there's really no big deal if the server opens about 100 connections at once, if it's hit with 100 users eh? We're coding an intranet and I'm just concerned that this will bog it down?<BR><BR>Thanks again. 
<BR><BR>ChrisHere is what I think they mean by that. You can only have one open server-side recordset at a time per connection object. This has been true even in the older ADO. This doesn't mean that only one person using your site can access the database at one time. If another person comes along and wants to connect and the connection is busy, the server will open up a new one. This is called connection pooling and is done for you automaticly. <BR><BR>I think there are a couple of reasons why they might stress this more with .net. One reason is because .net is much more easily multi-threaded, there is a greater chance of accidentily using a busy connection object to run a query. Another that is more important to ASP.net is that the connection object should always be explicitly closed for every page. ASP.net's garbage collection takes alot longer to clean up a forgotten connection object than ASP would.<BR><BR>One of the best ways to avoid locking a connection would be to use DataAdapters to fill DataSets rather than using DataReaders. They will run and finish up the query right away, but use more web server memory to hold the results (like disconnected recordsets in ADODB). As long as your page opens up its own connection object for its data, and closes it when its done, there really isn't anything to worry about.Thanks for the info... So there's really no big deal if the server opens about 100 connections at once, if it's hit with 100 users eh? We're coding an intranet and I'm just concerned that this will bog it down?<BR><BR>Thanks again.