Zitat von
Robert_G:
Mal eine Frage...
Welchen Vorteil versprichst du dir oder einem unschuldigen CodeLib-Leser von dieser Vorgehensweise?
Mit jedem Aufruf ändert sich der Code des Statements...
Diese Vorgehensweise ist für den Fall gedacht, das der Benutzer
bestimmte Anfragen stellen möchte und die Anwendung die
SQL-Abfrage
dynamisch zur Laufzeit zusammenbauen muss.
Ausserdem kann die generierte
SQL-Abfrage gespeichert
(z.B. in Datei
AuftragsbestandJan2004.SQL ) und später wieder geladen werden.
Die Beschleunigung der
SQL-Abfragen durch einen Statement-Cache ist dabei
nicht so wichtig, da die Abfrage nur ein oder zweimal gestellt wird.
Für Abfragen, die nicht dynamisch aufgebaut werden, kommt diese Vorgehensweise
natürlich nicht in Betracht. Hier würde man eine
Query auf das Formular/Datenmodul
ziehen und eine
SQL-Anweisung mit Parametern zur
Entwicklungszeit angeben.
Ich benutze diese Konvertierungs-Funktionen auch für den Export eines Datasets in
SQL-INSERT Statements.
Man kann sich z.B. an Datenbank A aus Tabelle Test eine Text-Datei mit
INSERT-Anweisungen erzeugen lassen und an Datenbank B wieder einspielen.
Siehe mein Programm
ADO-Desk.
Ich hätte vielleicht als Beispiel nicht eine SELECT Abfrage, sondern
eine INSERT oder UPDATE Anweisung wählen sollen.
Connection.Execute('UPDATE Auftrag SET LieferDatum='+DateTimeToSQLServerDateTimeString(now));