Seitdem sie mit SQL-Server-2005 eingeführt wurde, bin ich ein Fan der neuen Fehlerbehandlung. Deswegen empfahl ich deren Einsatz auch gleich in unseren Richtlinien. Leider mussten wir kürzlich feststellen, dass sie unerwartete Nebenwirkungen hat. <\/p>\n
Wir setzen bei uns ganz gerne Stored-Procedure und Functions ein. Nicht nur wegen der – in der Regel – besseren Performance gegenüber den Alternativen, sondern auch weil man deren Implementierung ändern kann ohne das Anwendungscoding anpassen zu müssen. Jetzt hat ein Kollege in seine Stored-Procedure die alte @@ERROR-Fehlerbehandlung durch die Neue mit TRY-CATCH ersetzt und bekam einen hässlichen Fehler. Wir konnten das ganz leicht reproduzieren und sind im Gespräch mit Microsoft über das Verhalten. <\/p>\n
Wenn in der Stored-Procedure nun ein TRY-CATCH um das SELECT gemacht wird, dann treten in dem Szenario plötzlich ein Fehler auf, weil der Rücksprung auf dem Cursor nicht mehr möglich ist. Auch parallel geöffnete, andere Client-Cursor – auf der gleichen Connection – können nicht mehr parallel gelesen werden.<\/p>\n
Das liegt daran, dass der SQL-Server anstelle des Static-Cursors auf der Server-Seite plötzlich ein Default-ResultSet ("forward-only\/read-only", auch als "Firehose"-Cursor" bekannt) verwendet. Und das kann freilich keine Rücksprünge. Das Default-ResultSet belegt ja bekanntlich auch die ganze Connection und verhindert das andere Cursor ausgelesen werden bis das Default-ResultSet wieder geschlossen wurde. (MARS hilft bei Verwendung der "alten" Schnittstellen wir MFC übrigens auch nicht wirklich weiter.) Schade, dass das von Microsoft nicht dokumentiert wurde.<\/p>\n
Wer denkt, er sei mit seiner .Net-Anwendung aus dem Schneider, den muss ich leider enttäuschen, auch hier werden unter der Haube Cursors verwendet, um die Daten auszulesen. Aber freilich kommt es in der Regel nicht vor, dass auf den Cursors rumnavigiert wird. <\/p>\n
Daher werden wir wohl empfehlen müssen, dass die neue Fehlerbehandlung genau dann nicht eingesetzt wird, wenn das ResultSet mit einem Cursor ausgelesen wird, auf dem entweder rauf und runter navigiert wird oder parallel auf andere Cursor zugegriffen wird. Leider ist das bei den meisten unserer bestehen Windows-32-Anwendungen so. Erst die neue Programmgeneration geht anders vor…<\/p>\n","protected":false},"excerpt":{"rendered":"
Seitdem sie mit SQL-Server-2005 eingeführt wurde, bin ich ein Fan der neuen Fehlerbehandlung. Deswegen empfahl ich deren Einsatz auch gleich in unseren Richtlinien. Leider mussten wir kürzlich feststellen, dass sie unerwartete Nebenwirkungen hat. Wir setzen bei uns ganz gerne Stored-Procedure und Functions ein. Nicht nur wegen der – in der Regel – besseren Performance gegenüber […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[16],"tags":[303,305,304],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/1470"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=1470"}],"version-history":[{"count":1,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/1470\/revisions"}],"predecessor-version":[{"id":1471,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/1470\/revisions\/1471"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=1470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=1470"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=1470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}