Having the transaction be associated with a Connection class rather than having a separate Transaction class enforces the semantic that each Connection can only have a single associated Transaction. Although this is the way most relational databases (including SQL Server) work today, that is not the way all data stores work (or might work in the future).
OLE DB represented the transaction by an ITransaction pointer, ADO simplified this by having a single transaction associated with an ADO.Connection. In ADO.NET, Connection.BeginTransaction returns a Transaction instance which must be associated with every Command that partipates in the transaction. You call Transaction.Commit or Transaction.Rollback. This is much more flexible, extensible, and OLE DB-like. Hope this helps, Bob Beauchemin [EMAIL PROTECTED] -----Original Message----- From: Sean Greer (SBI-Chico) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 23, 2002 1:16 PM To: [EMAIL PROTECTED] Subject: [DOTNET] OleDbConnection Question Why did they not make the current transaction available through the OleDbConnection class? It is truly a pain in the a%# to be forced to pass the transaction to every object that is going to do a database operation when they could of made it available via a public property on the connection object (e.g., OleDbConnection.CurrentTransaction). Any comments on this? Seang 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.
