Re: TableAdapters and Transactions again!

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

OK. I thought I could loop through a dictionary collection of say
'ITransTableAdapter' interfaces. The business layer can add all the TAs in
and then call them by the key once they have been enlisted in the
transaction.

Yep that sounds awrite. (Also see a comment about DbConnectionScope below).


Can I start a transaction on the first adapter in the loop and then pass
it to each subsequent adapter in the collection?

Yeah that should work out just fine.

Can you give me an idea of how the EnlistInTransaction method might look?

It should be very similar to a single table adapter scenario; take in a
transaction object, and a connection object. The connection needs to be
open.

BTW - Alazel Acheson from the MSFT ADO.NET team once blogged about something
called DbConnectionScope; (just search on it), he used an interesting design
pattern that you may find useful as well. His stuff was specific to Sys.Tx
though; but no reason why you couldn't use the same paradigm.

- Sahil Malik [MVP]
http://blah.winsmarts.com






"J055" <j055@xxxxxxxxxxxxxxxxx> wrote in message
news:%23$ux$BE%23GHA.4388@xxxxxxxxxxxxxxxxxxxxxxx
Hi

I hope you like the book - even though I've advocated against
TableAdapters in Chapter 3 :) for the very reasons you are running into.

Yes, the lack of support for transactions has caught me out a bit.

Anyway, the idea of factory would be something as simple as creating an
EnlistInTransaction method on each TableAdapter. You could then have each
TableAdapter implement a specific custom interface, and then you could
create a class on top that calls EnlistInTransaction for every instance
of that interface passed in.

OK. I thought I could loop through a dictionary collection of say
'ITransTableAdapter' interfaces. The business layer can add all the TAs in
and then call them by the key once they have been enlisted in the
transaction.

Can I start a transaction on the first adapter in the loop and then pass
it to each subsequent adapter in the collection? Can you give me an idea
of how the EnlistInTransaction method might look?

Does this sound reasonable? It's a bit messy using keys but I can't think
how else to do it.

I think it's starting to look like a workable plan. Your comments will be
very much appreciated.

Thanks again
Andrew




.

Relevant Pages

  • RE: Problem sending transactional Msmq messages with 2004 adapter
    ... The MSMQ adapter, also known as MSMQ/C adapter, allows ... non-transactional, public and private, and local and remote queues. ... Creates a new batch enlisting in the same original transaction and moves ... original transaction; otherwise, it rolls back the messages to the queues. ...
    (microsoft.public.biztalk.server)
  • Re: Help, SQL adapter deadlocked!!!
    ... The SQL port always creates the transaction across the called stored ... adapter is Serializable. ...
    (microsoft.public.biztalk.general)
  • Re: TableAdapters and Transactions again!
    ... every adapter, the following code is a generic method that works on any ... SqlTransaction transaction) ... foreach (SqlCommand command in commands) ... always null after I created the TableAdapter. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: SQLCE, DataAdaptors, MultipleTables, Updates and Inserts
    ... >> Do one update and then the other, within a transaction if you want to. ... >> connection from two different threads at the same time. ... > Set Insert/Update commands on adapter for table1 ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: SQL Port: using of the ROLLBACK
    ... As you stated the adapter is trying to Commit ... or Rollback a Transaction with @@Trancount = 0, ... If you open up the Component Services SnapIn on the BizTalk ... Event Category: BizTalk Server 2004 ...
    (microsoft.public.biztalk.general)