is there a way to use datasets in a connected way rather than disconnected?<BR><BR>the reason i ask is that i have the fear that if i can only use disconnected data in ado.net i may end up with a problem such as the following:<BR><BR>user A grabs a set of data and modifies it. at some point after user A grabbed the data and before he updated it and sent it back to the db, user B did the exact same thing. therefore, user B's modifications to the data are overwritten by user A's changes.<BR><BR>so, is there a way to connect to the db and remain connected, thereby locking out other users from the possibility of modifying data that you are working with? or does this have to be done using transactions in sqlserver?<BR><BR>thanks for you help<BR><BR>
I haven't heard of a way to use a connected dataset. This seems unlikely because a DataSet object is unaware of its data source to begin with, so would it be able to explicitly maintain a data connection? I really don't know, myself. I'm simply playing devil's advocate.<BR><BR>It may be fairly simple to build a table that will house a temporary index of records that are presently being accessed by users on a web site that is data aware. Checking this index table each time would certainly not be efficient, but may get the job done. The more users you have to potentially access a database, the bigger your concurrency concerns will be, and therefore with this method, you will most certainly lose valuable processor resources.<BR><BR>Another option could be to keep a snapshot of the data in memory. Before updating the data after a user has manipulated it, we could check the data to ensure that changes haven't already been made.<BR><BR>You have probably already come up with these ideas yourself. I think it will be interesting to see how the ASP.NET team addresses this very important question in the future.Having had the chance to speak to a couple of guys from the ADO.NET team at TechEd, I think I can fairly safely say "No - you cannot use the dataset in a connected manner". The whole idea of the dataset is that it doesn't actually connect to a datasource at any point - that is handled by a DataAdapter.<BR><BR>Anyway, this problem arises in traditional ASP too, since a transaction cannot span multiple page requests (unless you do hideous things like storing open connections in Session scope). There's never been an in-built means of saying "When user A views this page, lock all the data until they sumbit an update" - what if they just close their browser right there?<BR><BR>These sort of locking schemes are only really relevant in desktop development, where you know that you're connected to the client. Remember, in ASP (and ASP.NET) all objects go out of scope when the page is rendered, so your database connection and it's associated locks are toast before user A even sees the page.<BR><BR>DuncDataSets automatically disconnect from the database as soon as they are populated - so they can not be used in a connected state. The problem you pose is easily solved as follows:-<BR><BR>You must maintain state in your server (web form) code<BR>On each postback retrieve your dataset from the stored state<BR>When ready to update your data will be marshalled against the exising entries in the database, those that can be updated will be, those that cannot will not be and the results notified in the dataset.<BR>As I understanding it the dataset uses the underlying value to determine if a row in the database has changed - as ADO did previouly. <BR>
I haven't heard of a way to use a connected dataset. This seems unlikely because a DataSet object is unaware of its data source to begin with, so would it be able to explicitly maintain a data connection? I really don't know, myself. I'm simply playing devil's advocate.<BR><BR>It may be fairly simple to build a table that will house a temporary index of records that are presently being accessed by users on a web site that is data aware. Checking this index table each time would certainly not be efficient, but may get the job done. The more users you have to potentially access a database, the bigger your concurrency concerns will be, and therefore with this method, you will most certainly lose valuable processor resources.<BR><BR>Another option could be to keep a snapshot of the data in memory. Before updating the data after a user has manipulated it, we could check the data to ensure that changes haven't already been made.<BR><BR>You have probably already come up with these ideas yourself. I think it will be interesting to see how the ASP.NET team addresses this very important question in the future.Having had the chance to speak to a couple of guys from the ADO.NET team at TechEd, I think I can fairly safely say "No - you cannot use the dataset in a connected manner". The whole idea of the dataset is that it doesn't actually connect to a datasource at any point - that is handled by a DataAdapter.<BR><BR>Anyway, this problem arises in traditional ASP too, since a transaction cannot span multiple page requests (unless you do hideous things like storing open connections in Session scope). There's never been an in-built means of saying "When user A views this page, lock all the data until they sumbit an update" - what if they just close their browser right there?<BR><BR>These sort of locking schemes are only really relevant in desktop development, where you know that you're connected to the client. Remember, in ASP (and ASP.NET) all objects go out of scope when the page is rendered, so your database connection and it's associated locks are toast before user A even sees the page.<BR><BR>DuncDataSets automatically disconnect from the database as soon as they are populated - so they can not be used in a connected state. The problem you pose is easily solved as follows:-<BR><BR>You must maintain state in your server (web form) code<BR>On each postback retrieve your dataset from the stored state<BR>When ready to update your data will be marshalled against the exising entries in the database, those that can be updated will be, those that cannot will not be and the results notified in the dataset.<BR>As I understanding it the dataset uses the underlying value to determine if a row in the database has changed - as ADO did previouly. <BR>