Ich danke dir vielmals für deine Antwort,
SQL Code darf ich leider nicht zeigen, ist Firmeneigentum. Tut mir schrecklich leid (bin selber
OS-Verfechter, aber man muss ja von irgendwas leben).
Optimiert ist sie schon und sie läuft über ein eigenes StoredProc Objekt, in dem ich den Timeout höher setzen könnte. Das Problem ist, dies ist nur die Spitze des Eisberges, die längste Variante lief mal 45 Minuten (!!!). Ist ein Haufen Verarbeitung, was da dran hängt.
Momentan teste ich das weiterreichen der Exceptions, was mich auf dieses Verhalten von
ADO stießen lies. Der Aufbau ist so gestaltet, dass sich die SP an die Situation zur Laufzeit anpasst, was zum Teil Cursor unausweichlich macht und je nach Situation halt zu extrem langen Laufzeiten führt. Daher ist es auch schwer, gezielt eine
Exception auszulösen, wie in deiner Antwort beschrieben. Selbst wenn ich das tun würde, ich habe inzwischen folgendes Verhalten "rausfinden" (u. a. googel suche) können:
ADO "speichert" die Rückmeldungen bis zum Ende der Ausführung. Ist die erste eintreffende Meldung keine Fehlermeldung, hat man, wenn man Fehler abfangen will schon verloren, da
ADO nicht mehr abbricht, bis der Ablauf beendet ist. Man hat nun nur noch "Zugriff" auf die erste eingetroffene Meldung. Deshalb musste auch das NOCOUNT rein und es darf keine PRINT Anweisung enthalten sein. Das erste PRINT erzeugt eine Ausgabe, welche im Erfolgsfall "verschluckt" wird bzw. im Fehlerfall wird die erste PRINT Meldung ausgegeben, aber nicht die Fehlermeldung.
Aufgrund der Komplexität und evtl. Laufzeit der SP ist wohl bereits erkennbar, dass das Script entsprechend groß ist. Daher bin ich auf aufschlussreiche Meldungen im Fehlerfall angewiesen.
Eine Erhöhung des Timeout ist leider nicht möglich, ich müsste es wohl bei ca. 60 Minuten ansetzen um die evtl. größte Laufzeit mit abzudecken. Und dann würde ich im "echten" timeout-Fall 60 Minuten warten müssen, bis
ADO mir das meldet.
MfG McLane
Antwort
Zitat
Hybrid-Darstellung
