Skulle bara kolla om det är någon som har haft problem vid användandet av TransactionScope. Jag har jobbat lite med TrasactionScopes, och det kan förekomma problem just när den öppnar upp en förbindelse till Databasen. Detta beror på att den mjukvaran man använder för att kommunicera med databasen inte alltid stöder transactions typen. När får du det? Den smäller i SqlHelper=>DiscoverSpParameterSet när den försöker öppnar en connection, jag tror dessutom att det är den första som den öppnar (ska kolla det imorgon). Har du en brandvägg mellan din DB och klient? För det kan ställa till med problem när du kör med en distributed transaction. Testa följande: Det spåret har jag redan utrett, tyvärr...Problem med TransactionScope
Jag får följande problem vid exekvering: "The transaction has already been implicitly or explicitly committed or aborted."
Jag använder mig av en 3-skiktslösning där affärslagret initierar transaktionen. I botten så ligger SqlHelper-klassen från DAAB.
Förenklat ser flödet ut enligt följande:
UI => BLL (här startar transaktionen) => DAL => SqlHelper (Smäller här inne när den försöker öppna en Connection mot db)
Fick tips om att lägga till "enlist=false" i conn-strängen, detta fungerar men känns olämpligt. Någon som har någon input om detta.
Lägger upp kodexempel om någon behöver vid senare tillfälle.Sv: Problem med TransactionScope
Detta är kanske inte den bästa hjälpen men det kan vara en fingervisning.Sv: Problem med TransactionScope
Hur många connections öppnar du?
Görs det ngn transaction.commit ngnstans ( i DAAB tex?)Sv:Problem med TransactionScope
Ingen commit görs.
Det fungerar klockrent när man har db och klient på samma maskin.
Har du någon bra info om vad exakt enlist=false gör?Sv: Problem med TransactionScope
Lägg till "MSDTC.exe" till exception listan. Du kan också behöva lägga till port 135. Detta ska förhoppningsvis se till så MSDTC (som används om du går mot SQL Server 2000) kan fungera mot en databas som ligger bakom en brandvägg. Ofta brukar problemet kunna vara just brandväggen. Det har i alla fall varit vanligt hos de kunder jag har varit ute hos.
En beskrivning på enlist=false:
Som standard så kommer en SqlConnection att bli "enlisted" (bli en medlem av/värva, enrollera) i den transactions context som är igång. Om du inte vill att SqlConnection ska bli "enlisted" så sätter du den till false.
/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.comSv:Problem med TransactionScope
"En beskrivning på enlist=false"
Det var ungefär vad jag hade kommit fram till själv. Men betyder detta att om man har följande scenario...
Using myTransaction As New TransactionScope
Operation1 'Öppnar en egen conn
Operation2 'Öppnar en egen conn
Operation3 'Öppnar en egen conn
myTransaction.Complete()
End Using
...att dessa operationer inte kommer att ingå i samma transaction? För i såna fall så är det ju inget man vill använda!?