Hallo,

bei dem SQL-Server gibt es die Option SET PARSEONLY. Damit wird das Script nicht ausgeführt, sondern nur überprüft.

Wie erkenne ich nun, ob ein Fehler in dem SQL-Statement ist. Wie lauten die Rückgabewerte, wenn alles in Ordnung, bzw. ein Fehler aufgetreten ist?

Danke schon mal im Vorraus für eure Hilfe.

André

*push*

So ich zieh das Thema mal wieder hoch.

Hat noch keiner die Option "SET PARSEONLY" beim SQL-Server 2000 benutzt? Oder kennt ihr eine andere Art Scripts zu überpüfen, ob sie korrekt sind?

André

Hallo Andre,

also so wie ich es verstanden habe, aendert sich fuer dich (fast) nichts. Du fuehrst das Query aus, aber der Server parst es nur und gibt dir dann wie immer Exceptions oder was auch immer zurueck. Syntaktische Fehler kannst du somit rausfinden, aber andere Fehler (wie z.B. eine Constraint violation) nicht (er parst ja schliesslich nur). Ich hab hier allerdings keinen SQL-Server, bei dem ich das austesten koennte. Die Logik sagt mir aber, dass er dir bei Syntaxfehlern immer noch Exceptions um die Ohren wirft

Greetz
alcaeus

Zitat von alcaeus:

Hallo Andre,

also so wie ich es verstanden habe, aendert sich fuer dich (fast) nichts. Du fuehrst das Query aus, aber der Server parst es nur und gibt dir dann wie immer Exceptions oder was auch immer zurueck. Syntaktische Fehler kannst du somit rausfinden, aber andere Fehler (wie z.B. eine Constraint violation) nicht (er parst ja schliesslich nur). Ich hab hier allerdings keinen SQL-Server, bei dem ich das austesten koennte. Die Logik sagt mir aber, dass er dir bei Syntaxfehlern immer noch Exceptions um die Ohren wirft

Greetz
alcaeus

Wenn eine Exception kommt dann ist die Option irgendwie sinnlos. Dann kann ich das Script auch ausführen. Na ja trozdem danke.
Am Montag beschäftige ich mich dann wieder intensiver damit, jezt ist WE

Zitat von MagicAndre1981:

Wenn eine Exception kommt dann ist die Option irgendwie sinnlos. Dann kann ich das Script auch ausführen.

Naja, nicht ganz. So hast du die Gewissheit, dass dein Query zwar passt, die Datenbank aber noch lebt. Mir faellt im Moment zwar kein Einsatzgebiet fuer diese Option ein, aber bitte.
Und zu den Exceptions: ich wuerde die sowieso immer abfangen und selbst behandeln

Greetz
alcaeus

Zitat von alcaeus:

Mir faellt im Moment zwar kein Einsatzgebiet fuer diese Option ein, aber bitte.

Ich erstelle mir die Scripts zur Laufzeit des Tools aus einer Beschreibung von Business Objekten. Und deshalb würde ich jetzt gerne, zur Entwicklungszeit, die erstellten Scripts nur parsen und testen ob sie syntaktisch korrekt sind. Und dabei bin ich halt auf diese Option gestoßen.

Zitat von alcaeus:

Und zu den Exceptions: ich wuerde die sowieso immer abfangen und selbst behandeln

Das versteht sich von selbst Alle Exception werden behandelt.

André

Das Errors-Objekt einer ADO-Connection enthält etwaige Fehler des zugehörigen Resultsets. Eine Anfrage könnte mehrere Resultsets zurückliefern (select * from a; select * from b).
Du musst durch alle Resultsets durchiterieren und dann das Errors-Objekt abfragen.

Da bei SET PARSEONLY vermutlich keine Resultsets zurückgeliefert werden, tritt hier ein sonderfall ein. Beim Aufruf von ADOConnection.Execute gibt es eine option, sodass ADO eben nicht meckert, wenn nix zurückkommt. Check das mal.

Hi Leute,

das Problem hat sich erledigt. Bei Fehlern in der Syntax wird ein Fehler an den Client gesendet, den man mit der Klasse SqlException

Zitat:

ms-help://MS.NETFrameworkSDKv1.1/cpref/html/frlrfsystemdatasqlclientsqlexceptionclasstopic.htm

abfangen kann.

Das war alles.

Beim nächstem mal sollte ich die Hilfe doch noch intensiver lesen

Danke an alle, die hier mitgeholfen haben

André