That may be true, but it doesn't make any sense. We're talking about disconnected data. Why would you only want inherit a transaction from the select? My use-case is a multi-table DataSet where I am updating the database from the DataSet. Since the tables are related, I want a single transaction to filter through all the updates, though different DataAdapters (using one DataAdapter per table).
I have come to the conclusion that the only way to do this is to generate my own Command objects for the DataAdapters then set the Transaction for each command object. Please tell me how I am wrong. Thanks, Shawn Wildermuth [EMAIL PROTECTED] > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] > On Behalf Of Peter Stephens > Sent: Sunday, April 14, 2002 4:44 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] Transactions and CommandBuilders > > > > Shawn Wildermuth spake: > > > > I just want to confirm this. CommandBuilders and transactions are > > incompatible, right? Since the CommandBuilder generates > and destroys > > Command objects on the fly as needed, I assume there is no way to > > attach a transaction to the commands. I want to update a database > > with standard optimistic concurrency, but I want to wrap the entire > > thing in a local transaction to make sure that all table > updates are > > completed together. > > > > Ideas? > > No this is incorrect. The CommandBuilder requires a > SelectCommand (which is where the update metadata is > calculated from). When the CommandBuilder generates Update, > Insert, and Delete commands it inherits the Transaction > property from the Select command. > > -- > Peter > > You can read messages from the DOTNET archive, unsubscribe > from DOTNET, or subscribe to other DevelopMentor lists at > http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
