Benutzer mit den meisten Antworten
ExecuteReader & timeout - verursacht durch Transaktion ?

Frage
-
Ich habe hier ein eigenartiges Problem das möglicherweise seine Ursache im Aufruf während einer Transaktion hat:
1. Ich habe ein VB.net Kommandozeilenprogramm, dass u.a. Daten aus einer temporären Tabelle liest und dann weiter verwendet. Dieses Tool funktioniert wenn man es solo verwendet.
2. Dieses Tool wird innerhalb einer stored procedure über xp_cmdshell aufgerufen. In diesem Fall aber gibt es einen Fehler ausgerechnet in dem Programmteil, der mit Exceutereader die Daten aus der temporären Tabelle liest und zwar gibt es einen timeout.
3. Der Aufruf erfolgt innerhalb einer Transaktion
4. Irgendwo habe ich was gelesen, daß eine "uncommited transaction" das verursachen kann. Ist das wirklich so? Kann ich das irgendwie vermeiden ?
Antworten
-
insofern konnte ich kaum glauben, dass dies während einer Transaktion scheitert.
Wenn die Transaktion noch nicht commited wurde und nehmen wir mal an, das Lesen ginge, was für ein Ergebnis würdest Du erwarten? Ich würde eine leere Tabelle erwarten, da die Daten eben noch nicht commited wurden. Das Tool erst nach dem Commit aufzurufen, wäre das beste. Andere Lösung wäre ein "Dirty Read", den ich aber nicht empfehlen würde. Geht z.B. mittels des Table Hints "With (ReadUncommitted)" bzw. NoLock (ist das gleiche)
SELECT * FROM DeineTabelle WITH (NOLOCK)
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Administrator Freitag, 30. Januar 2015 09:36
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Freitag, 6. Februar 2015 06:56
Alle Antworten
-
Hallo Nico,
zu Punkt 2.: Von hinten durch die Brust ins Auge; wozu soll das Konstrukt gut sein?
zu Punkt 4.: Ja, daran wird es liegen. Wenn Du eine Transaktion startest, eine (temporäre) Tabelle erstellst, Du die mit Daten füllst, dann werden dabei Sperren erstellt und wegen Lock Escalation werden hier nicht Page Locks entstehen, sondern es wird die gesamte Tabelle gesperrt. Womit ich wieder bei Punkt 2 wäre, wozu? Warum nicht alles mit T-SQL auf SQL Server Seite?
Olaf Helper
[ Blog] [ Xing] [ MVP] -
@2 Das ist eine extrem gute Frage ...
Das Tool ist dazu gedacht, Einträge in öffentliche Ordner auf einem Exchange zu machen.
Im ersten Schritt habe ich das aus einer Access-Anwendung per VBA versucht - bin aber nicht zum Ziel gekommen. Ich habe wochenlang gegoogelt bis ich den jetzigen Lösungsansatz hatte. Ist sicherlich alles andere als toll aber es hat zumindest im ersten Ansatz funktioniert. Wenn jemand eine Alternative weiss - ich bin dabei!!!!
Dazu müssten zumindest Funktionen meiner DLL aus T-SQL heraus aufrufbar sein.
@4 Das Tool LIEST nur Daten aus der Tabelle aus , insofern konnte ich kaum glauben, dass dies während einer Transaktion scheitert.
Aber nach Studium deines Beitrages müsste es möglich sein, den Tool-Aufruf nach dem COMMIT zu platzieren - und dann müsste es doch laufen, sehe ich das richtig ?
-
insofern konnte ich kaum glauben, dass dies während einer Transaktion scheitert.
Wenn die Transaktion noch nicht commited wurde und nehmen wir mal an, das Lesen ginge, was für ein Ergebnis würdest Du erwarten? Ich würde eine leere Tabelle erwarten, da die Daten eben noch nicht commited wurden. Das Tool erst nach dem Commit aufzurufen, wäre das beste. Andere Lösung wäre ein "Dirty Read", den ich aber nicht empfehlen würde. Geht z.B. mittels des Table Hints "With (ReadUncommitted)" bzw. NoLock (ist das gleiche)
SELECT * FROM DeineTabelle WITH (NOLOCK)
Olaf Helper
[ Blog] [ Xing] [ MVP]- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Administrator Freitag, 30. Januar 2015 09:36
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Freitag, 6. Februar 2015 06:56
-
Hallo NicoNi,
Bist Du mithilfe von Olafs Hinweisen weitergekommen?
Gruß,
Dimitar
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.
- Bearbeitet Dimitar DenkovMicrosoft contingent staff, Administrator Freitag, 30. Januar 2015 09:35