SQL Syntax

[xaverras]

Hallo,

gelegentlich beutzte ich delphi für kleine Projekte ( ich weis, dass Delphi eniges mehr kann ). Aus einem anderen Projekt
habe ich die folgende Anweisung, die ich nicht ganz verstehe:

SQL.Strings[1]:='from call_cdrs_'+cboMonat.Text;

zwar ist klar damit wird die Sql Anweisung ist auf der Wert des ausgewählte Monat gesetzt, was ich nicht verstehe ist die eins in ekige Klammer,
auf was bezieht sich, oder besser gesagt wie funktioniert es.

Die komplette SQL Anweisung wäre:

Select call_date, call_time, terminating_cli, call_duration, subtotal
from call_cdrs_10
where originating_cli=:identifier

was würde das ändern wenn ich z.B SQL.Strings[0], oder SQL.Strings[2] schreibe?

Danke

Xaver

[alcaeus]

Hallo xaverras,

die SQL-Property der Queries ist vom Typ TStrings, was eigentlich nur ein Array von Strings ist (mit ein paar zusaetzlichen Methoden). Mit Strings[1] greifst du auf die zweite Zeile zu, vorausgesetzt sie ist da. Ich empfehle dir aber, dich nicht drauf zu verlassen, sondern so zu arbeiten:

Delphi-Quellcode:

with SomeQuery do
begin
  Close;
  SQL.Clear;
  SQL.Add('SELECT call_date, call_time, terminating_cli, call_duration, subtotal FROM call_cdrs_10 WHERE originating_cli = :identifier');
//Parameterzuweisung
  Open;
end;

Sonst kann es leicht passieren, dass du das falsche ueberschreibst bzw. in eine Zeile schreiben willst, die nicht existiert (gibt eine Fehlermeldung: List index out of bounds).

Greetz
alcaeus

[Hansa]

Kann mir die Antwort ersparen. Alcaeus war schneller. :evil: :mrgreen: Wenn ich aber schon dabei bin, noch folgende Anmerkung : die SQL-Strings können sehr lang und unübersichtlich werden. Deshalb sollten sie nicht in eine Zeile gepackt werden. Deshalb TStrings. Die Hauptgefahr besteht aber dann darin, das Clear zu vergessen ! Außerdem sollte man Add verwenden und nicht [1] usw.

[xaverras]

Erstmal Danke für die Antwort.

Wenn ich richtig verstehe jede Zeile ist eine Element des Array,
somit:

Select call_date, call_time, terminating_cli, call_duration, subtotal // = SQL.Strings[0]

from call_cdrs_10 // = SQL.Strings[1]

where originating_cli=:identifier // = SQL.Strings[2]

und wenn die Anweisung alles in einer Zeile stehen würde dann wäre nur über "SQL.Strings[0]" zu erreichen,

z.B:

Select call_date, call_time, terminating_cli, call_duration, subtotal from call_cdrs_10 where originating_cli=:identifier // = SQL.Strings[0]

Grüße.

Xaver

[alcaeus]

Hallo xaver,

das ist richtig so. Du koenntest das Query auch aufteilen:

Delphi-Quellcode:

with SomeQuery do
begin
  Close;
  SQL.Clear;
  SQL.Add('SELECT call_date, call_time, terminating_cli, call_duration, subtotal ');
  SQL.Add('FROM call_cdrs_10 ');
  SQL.Add('WHERE originating_cli = :identifier');
//Parameterzuweisung
  Open;
end;

Dann hast du die von dir genannte Aufteilung. Wie gesagt, ich rate aber davon ab, direkt auf eine Zeile zuzugreifen. Man weiss ja nie was passiert ist ;)

Greetz
alcaeus

[xaverras]

noch eine Frage, wie ist die Syntax der Parameterzuweisung, wäre's möglich ein Beispiel?
Danke.

Xaver

[omata]

Moin,

ich würde von dieser ADD-Geschichte abraten
(wenn überhaupt dann APPEND, weil das eine Prozedur ist)

Delphi-Quellcode:

  SomeQuery.Close;
  SomeQuery.SQL.Text:=
    'SELECT call_date, call_time, terminating_cli,'#13 +
    '       call_duration, subtotal'#13 +
    'FROM call_cdrs_10'#13 +
    'WHERE originating_cli = :identifier';

  //Parameterzuweisung
  SomeQuery.ParamByName('identifier').AsInteger:=1;
  //oder auch
  SomeQuery.ParamByName('identifier').AsString:='1';

  SomeQuery.Open;

Bei den neueren Datenbankkomponenten (z.B. DbExpress) gibt es keine SQL-Eingenschaft (alla TStrings) mehr, dort ist nur noch ein String (CommandText) vorhanden. Wenn man irgendwann von der veralteten BDE und deren Komponenten weg will, hat man es mit der oben beschriebenenen Vorgehensweise, wesentlich einfacher. Ausserdem gibt es so nicht das geschilderte Clear-Problem.

MfG
Thorsten

[Hansa]

Zitat:

Zitat von omata

Moin,

ich würde von dieser ADD-Geschichte abraten
(wenn überhaupt dann APPEND, weil das eine Prozedur ist)
...Bei den neueren Datenbankkomponenten (z.B. DbExpress) gibt es keine SQL-Eingenschaft (alla TStrings) mehr, ...

Letzteres bedeutet aber dann eher, daß sie inkompatibel zu TDataSet sind und deshalb ausscheiden sollten. Das wäre die logische Konsequenz und nicht das Add abzuschaffen. 8) Dabei geht es lediglich darum, einen simplen String zusammenzubauen und an die DB zu schicken. Was soll denn da das Append besser machen und was verstehst du unter "Prozedur" ?

[omata]

Moin,

Zitat:

Zitat von omata

ich würde von dieser ADD-Geschichte abraten
(wenn überhaupt dann APPEND, weil das eine Prozedur ist)
...Bei den neueren Datenbankkomponenten (z.B. DbExpress) gibt es keine SQL-Eingenschaft (alla TStrings) mehr, ...

Zitat:

Zitat von Hansa

Letzteres bedeutet aber dann eher, daß sie inkompatibel zu TDataSet sind und deshalb ausscheiden sollten. Das wäre die logische Konsequenz und nicht das Add abzuschaffen. 8) Dabei geht es lediglich darum, einen simplen String zusammenzubauen und an die DB zu schicken. Was soll denn da das Append besser machen und was verstehst du unter "Prozedur" ?

also ADD liefert einen Integer zurück (die Einfügeposition) und ist deshalb eine Funktion. APPEND liefert keinen Rückgabewert und ist deshalb eine Prozedur. Wenn man die Erweiterte Syntax in Delphi an hat kann man Funktionen so aufrufen, wie Prozeduren. Dies ist natürlich wunderschön, aber warum soll man eine Funktion benutzen, wenn es dafür eine identische Prozedur gibt, die den nicht benötigten Rückgabewert nicht hat. Ich fand nur, wenn man diese Möglichkeit der ADD-Geschichte erwähnt, warum kann man dann nicht die elegantere Lösung erwähnen.

So, und zu dem zweiten Punkt. Natürlich ist das TDataSet nicht zur TQuery kompatibel. ABER, wenn man von der BDE (TQuery) Struktur umsteigen will auf z.B. DbExpress dann ist man wesentlich schneller beim Umbau des Quellcodes als wenn man die TStrings.Add bzw TStrings.Append Struktur benutzt.

BDE-Variante:

Delphi-Quellcode:

var Query:TQuery
begin
  Query:=TQuery.create(Self);
  try
    Query.Databasename:=Database.Databasename;
    Query.Sessionname:=Database.Sessionname;
    Query.SQL.Text:=
      'SELECT *'#13 +
      'FROM tabelle'#13 +
      'WHERE a = :a'#13 +
      'ORDER BY b';

    Query.ParamByName('a').AsInteger:=1;
    Query.Open;
    while not Query.Eof do begin

      Query.Next;
    end;
    Query.Close;
  finally
    Query.free;
  end;
end;

DbExpress-Variante:

Delphi-Quellcode:

var SDS:TSimpleDataSet;
begin
  SDS:=TSimpleDataSet.create(Self);
  try
    SDS.Connection:=SQLConnection;
    SDS.DataSet.CommandText:=
      'SELECT *'#13 +
      'FROM tabelle'#13 +
      'WHERE a = :a'#13 +
      'ORDER BY b';

    SDS.DataSet.ParamByName('a').AsInteger:=1;
    SDS.Open;
    while not SDS.Eof do begin

      SDS.Next;
    end;
    SDS.Close;
  finally
    SDS.free;
  end;
end;

Ich will hier niemanden zu etwas zwingen oder super lange auf meine Meinung beharren. Nehmt meinen Vorschlag an oder nicht - mir ist das sowas von egal. Ich wollte euch nur an meiner Erfahrung teilhaben lassen. Habs nur gut gemeint.

PS: Mir ist gerade noch etwas eingefallen. Wenn man nur solche kleinen SQL-Anweisungen schreibt, kann
das durchaus so aussehen, als ob das egal wäre - der Umbau ist dann natürlich sehr einfach.
Ich schreibe aber häufiger mal SQL-Anweisungen mit >100 Zeilen und da macht dann diese
ADD-/APPEND-Geschichte keinen Spass mehr.

MfG
Thorsten

[xaverras]

Hallo Thorsten,

ich finde es doch Interessant, nur sollte es du etwas ( für mich zumindestens ) verständlicher darlegen. Geht es auch mich den Zeos?

Grüße.

Xaver