none
ExecuteReader & timeout - verursacht durch Transaktion ? RRS feed

  • 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 ? 

    Dienstag, 20. Januar 2015 22:50

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]

    Mittwoch, 21. Januar 2015 09:33

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]

    Mittwoch, 21. Januar 2015 07:03
  • @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 ?

    Mittwoch, 21. Januar 2015 09:08
  • 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]

    Mittwoch, 21. Januar 2015 09:33
  • Ich bin nicht wirklich weiter. Ich versuche gearde, die ganze Geschichte für CLR zu modifizieren, aber auch da stosse ich auf grundlegende Probleme noch bevor die Funktion überhaupt aufgerufen wird.

    Sonntag, 25. Januar 2015 06:40
  • 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.

    Freitag, 30. Januar 2015 09:35
    Administrator