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

[Hansa]

Zitat:

Zitat von omata

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.
...
Ich schreibe aber häufiger mal SQL-Anweisungen mit >200 Zeilen und da macht dann diese ADD-/APPEND-Geschichte keinen Spass mehr.

Wen interessiert denn welche Einfügeposition ? :shock: Ehrlich gesagt verstehe ich nicht, was du meinst. Und wenn die SQL-Anweisung sehr groß wird, na und ? 200 Zeilen sind doch nicht die Welt. Dann wirds allerdings Zeit, einiges aus Delphi zu verlagern. Frage mal Daniel, was Software-Engineering bedeutet. 8)

[omata]

@xaverras
Also, ich versuche es gern nochmal...

Die Eigenschaft SQL in einer TQuery oder auch TZQuery ist vom Typ TStrings und diese Liste enthält dann einfach den SQL-String. Mit Add oder Append können dann Zeilen hinzugefügt werden. Bei dieser Vorgehensweise muss man aber darauf achten, dass man SQL.Clear aufruft. Damit die alte SQL-Anweisung gelöscht wird, weil die Add bzw. Append Methode nur neue Zeilen anhängt.
Deshalb habe ich erwähnt, dass es sinnvoll ist mit SQL.Text:=''; den SQL-String zusetzen, dann hat man niemals Probleme mit irgendwelchen alten SQL-Resten. Man setzt einfach den kompletten SQL-String neu. Übrigens das haben sich wohl auch die Designer der neuen Datenbankkomponenten so überlegt. Dort ist es nämlich nur noch ein String.
Die Zoes-Komponente TZQuery ist identisch mit der TQuery in meinem Beispiel.

Da ein String in Delphi nicht mehr als 255 Zeichen haben darf (in einer Zeile) und das ja auch sehr unübersichtlich wäre, habe ich mal einen Vorschlag in meinen Beispielen aufgezeigt, wie man die SQL-Anweisung übersichtlich darstellen kann und alles in einem langen String zusammenfassen kann.
Das Zeichen #13 steht dabei für einen Zeilenumbruch. Dieser ist nicht so wichtig. Lässt man ihn allerdings weg, so muss jede Zeile mit einem Leerzeichen beendet werden, damit die SQL-Anweisung funktioniert.
Und als zusätzlichen Vorteil dieser Stringübergabe habe ich einfach noch erwähnt, dass es bei einem Umstieg auf neue Datenbankkomponenten bei dieser Vorgehenweise einfacher ist die Struktur umzubauen.

So, ich weiss nicht ob ich nun alle deine offenen Fragen beantwortet habe. Hoffe aber, es hilft dir weiter.

@Hansa

Zitat:

Zitat von Hansa

Wen interessiert denn welche Einfügeposition ? :shock: Ehrlich gesagt verstehe ich nicht, was du meinst.

Genau, wen interessiert die Einfügeposition. Das ist doch genau das was ich gemeint habe. APPEND liefert diese Information nicht und ADD liefert sie. Also wieso ADD?

Zitat:

Zitat von Hansa

Und wenn die SQL-Anweisung sehr groß wird, na und ? 200 Zeilen sind doch nicht die Welt. Dann wirds allerdings Zeit, einiges aus Delphi zu verlagern. Frage mal Daniel, was Software-Engineering bedeutet. 8)

ich wusste das, dass so ein Kommentar kommen musste. Eben nicht. Die Verlagerung würde nur bedeuten, das man irgendwelche unübersichtlichen Proceduren auf dem Server ablegen würde. Das macht das Software-Engineering nicht gerade übersichtlicher, wenn man es mit sehr vielen unterschiedlichen Anwendungen zu tun hat. Ausserdem sind diese großen Abfragen absicht, weil viele kleine Abfragen nicht so vom DB-Server optimiert werden können, als eine etwas größere, die dann aber alle Informationen bereit stellt.

Also, wie auch immer. Macht doch was ihr wollt...

Thorsten