Parametrisierte Abfragen in ADO.NET

[hfr]

Hallo alle zusammen,

der Einsatz von parametrisierten Abfragen wird ja gemeinhin empfohlen - vor allem hinsichtlich der Sicherheit.
Ich stehe allerdings vor der Aufgabe, dass alle gegen die Datenbank (MS-SQL-Server 2005) ausgeführten SQL-Befehle mit zu protokolieren sind. Hierbei nützt es mir leider wenig, wenn in der Log-Tabelle dann lediglich Anweisungen wie bspw. "UPDATE table SET date=@date WHERE order_id=@ID" stehen.

Besteht die Möglichkeit, den substituierten SQL-String irgendwie auszulesen?
Die CommandText-Property der SQLCommand-Komponente liefert ja ebenfalls nur den parametrisierten String zurück.
Es ist dabei unerheblich, ob der substituierte Befehl vor oder nach Ausführung zurück gegeben wird (besteht z.B. die Möglichkeit den letzten Befehl vom SQL-Server zu erhalten?).

Ich hoffe, Ihr könnt einem SQL-Server-Neuling helfen und wünsche allen einen schönen Tag.

Hagen

[das-d]

den Parameter kenn dein Programm ja. Also entweder loggst du beides nach dem Motto:

Befehl: Commandtext - Parameter: Parameter1, Parameter2 ...

oder du ersetzt im Commandtext die Platzhalter selbst zum loggen. Eine andere Möglichkeit kenne ich nicht allerdings heißt es nicht dass es keine andere gibt

[Ralf Jansen]

Besteht die Möglichkeit, den substituierten SQL-String irgendwie auszulesen?

Nein. Denn es wird nicht substituiert. Der Optimizer des SQL Servers wird erst die SQL Abfrage(ohne konkrete Parameterwerte) optimieren und in eine entsprechende datenbankspezifische Abfragefolge übersetzen und diesen dann erst mit den konkreten Parameterwerten ausführen. Wenn du auf dem Client loggen willst wirst du wohl das SQL Statement und die Parameter einzeln loggen müssen.

[das-d]

jetzt wollte ich dir gerade empfehlen dass du eine Klasse schreibst die von SqlCommand erbt, und die dir den Comman sozusammenbaut wie er sein wird und als zusätzliche Property bereitstellt. Leider hab ich gesehen dass die Command Klassen NotInheritable sind. Naja musst dir fürs Logging halt eine Zusätzliche Funktion schreiben.

[hfr]

Hallo,

danke erst einmal für die schnellen Antworten.
Dann werde ich Euren Rat befolgen und meine Logging-Tabelle entsprechend umbauen.
Die Idee von das-d, zum Loggen die Parameter im CommandText zu ersetzen ist eine gute Idee, zumal das dann den Charme hat, auch beim Debuggen sich einen "ordentlichen" SQL-String zurückgeben lassen zu können.
Wie haltet Ihr es denn mit parametrisierten Abfragen? Verwendet Ihr sie eigentlich lieber als (meist kaum lesbare) String-Verkettungen?

Einen schönen Tag

Hagen

[Ralf Jansen]

Wie haltet Ihr es denn mit parametrisierten Abfragen? Verwendet Ihr sie eigentlich lieber als (meist kaum lesbare) String-Verkettungen?

Entweder ich benutze einen ORM der SQL intern generiert oder ich benutzte typisierte Tableadapter. Der interen SQL Teil(unabhängig von der herangehensweise) wird üblicherweise mit Parameteren gelöst außer bei komplexen Suchanfragen deren WHERE Klauseln dynamisch zusammengesetzt werden. Wenn man Dutzende mögliche Bedingungen hat die beliebig kombionierbar sind sind Lösungen mit Parametern nicht praktikabel.

Worauf ich eigentlich hinaus will ist aber das im eigentlich Programmcode bei mir sicherlich kein Inline SQL Abfragen zusammengebastel stattfindet sondern das Ganze in einer dezidierten Klasse die nichts anderes macht und das möglichst abstrakt. Ob das dann nun schon aussieht wie das SQL entsteht ist sekundär.

Bei der Entscheidung für Parametern sollten dir Punkt wie Performance, Sicherheit, Wartbarkeit etc. wichtiger sein.