c# - TansactionScope and MSDTC enlisting issues -

i have been researching solutions issue facing. using transacitonscope wrap looping code save data sql 2005. have had revert using string , splitting in proc, when string length > 8000 split , working great on our test env sql 2008r2. issue when move testing sql 2005 environment transaction automatically enlisted msdtc. 2005 env different e.g. different domain , behind firewall etc sql server handle transaction rather msdtc. have traced sql 2005 db , can see dtc transactions in trace, when tracing sql2008 using sql transactions in trace.

the code simple - using statement (transactionscope ...), there loop within using block loop between 1 , 4 iterations @ , in loop there code newing sql connection same db, , there implicit sqltransaction created off connection (which there resolve single updates). cannot pass same newed connection code in data access layer, testing sql2008 must ok new connections same db (new pooled believe). each loop actual update call db. if if string 1200 char length there 2 calls update db...

based on posts e.g. sqlconnection , avoiding promotion msdtc

there setting can passed connection string enlist=false, understanding keep management of transaction sql server , work provided using same database resource - in case same sql 2005, newed connections including connection.begintransaction in each loop - can confirm this? or using connection setting enlist=false dangerous in case?

update: rephase, there caveat using enlist=false in connection string, when using transcationscope, sql 2005, , code looks (pseudo code):

using (var ts = new transactionscope)     {      loop (twice)      {                using (var conn = new sqlconnection)          using (var tran = conn.begintransaction)          {              //do update db code here;               tran.commit();          }     }      ts.complete(); } 

if not enlist connections (which possible) transactionscope has no effect. don't want that.

if enlist multiple sqlconnections distributed transaction design. fundamentally so. if lucky, both use same internal pool connection , avoid using msdtc (and instead use sql server lightweight distributed transactions). this, however, never guaranteed , subject timing issues. performance optimization. hate optimization because during testing happens , masks underlying issue.

don't open multiple connections. reuse same connection.