Zitat von
Elvis:
Hab' mich gerade mal schlau gemacht. Anscheinend gibt es keine hübsche Lösung dafür.
Ich zwischenzeitlich auch, und das scheint alles nicht so toll zu sein.
Zitat von
Elvis:
Das Errorhandling von TSQL ist einfach zu schrottig.
naja, immerhin kann man jetzt wenigstens gegenüber der 2000er Version die Fehler in einem Try...catch Block abfangen.
Zitat von
Elvis:
Wie wär's mit einem Output parameter, der den Error code angibt?
Das Problem ist, dass einiges als Funktion deklariert sein muss, da die Funktion weiter in Select-Abfragen genutzt werden soll. Es hilft mir leider nicht weiter eine T-
SQL funktion zu deklarieren, die intern ein Stored Procedure aufruft, denn dann hab ich wieder die gleichen Probleme mit dem Raise Error weil der .NET Aufruff im Kontext der T-
SQL Funktion aufgerufen wird.
Aber dein obiger Ansatz funktioniert... Für Stored Procedures. Neben lesenden (über Funktion) Zugriff auf Funktionen gibts auch schreibende Stored Procedures, die mit dem gleichem Webservice kommunizieren. Da krieg ich die Fehler abgefangen und kann sie an den Aufrufer mittels raiserror dort auch genau so anzeigen und auswerten.
Zitat von
Elvis:
Tja, was bringt einem CLR Integration wenn das
DBMS noch genauso dämlich ist wie 2000?
Das
DBMS an sich wird dadurch nicht schlecht. Die .NET Integration ermöglicht uns hier zumindest Dinge, die unter 2000 ganz einfach nicht möglich waren.