<comments_inline> > Shawn Wildermuth spake: > > 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?
But the built in command builder (via the associated data adapter) requires a select statement to determine column mappings (and other metadata) from the base tables in the database. It is more of a hack (and from my reading, undocumented) that the CommandBuilder uses the Transaction property from the SelectCommand on the data adapter. This of course does not mean that you have to use the transaction when you run the SelectCommand initially--only when you supply the SelectCommand for updating the database. > 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. I built my own CommandBuilder because a) I did not want the additional round trip to the server just to determine update metadata; and b) I wanted to implement last in update logic whereas the standard CommandBuilder only supports full optimistic, where every column that changes is appended to the WHERE clause to detect db changes. On my CommandBuilder I just created a Transaction property to be set when a transaction is required. This is a better design IMHO. --- Peter You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
