ADOQuery - SQLQuery ??

[p80286]

@haentschmann
Ich gehe mal davon aus, das die Kommentare von Dir sind

Delphi-Quellcode:

ADOQuery1.SQL.Clear; // kann weg wenn du SQL.Text verwendest
ADOQuery1.SQL.Add('select * from taccounts where susername='''+edit1.Text+''' and suserpass='''+edit2.Text+''' '); // besser Parameter und SQL.Text

Das scheint hier grundsätzlich so gelöst zu werden

Delphi-Quellcode:

Query.SQL.Text

wir wohl nur von den wenigsten Komponenten angeboten.

Delphi-Quellcode:

 if not ADOQuery1.Eof then // du erwartest nur einen Datensatz, warum die Bedingung auf EOF?
   begin

Wenn nach

Delphi-Quellcode:

.Open

Delphi-Quellcode:

.EOF

wahr ist, gibt es kein Ergebnis, das ist schon ganz in Ordnung. Was dann allerdings passiert, gehört meiner Meinung nach nicht dorthin.

Gruß
K-H

[haentschman]

Ok, Ok jeder hat seine Meise...:zwinker:

Zitat:

Wenn nach .Open .EOF wahr ist, gibt es kein Ergebnis,

Korrekt...Normalerweise gehören EOF und while bei mir zueinander. Bei einem einzelnen Datensatz prüfe ich auf IsEmpty. Intern macht das nix anderes...nur ich kann es direkt auseinanderhalten. 8-) (Liste oder einzeln)

Zitat:

Das scheint hier grundsätzlich so gelöst zu werden Query.SQL.Text wir wohl nur von den wenigsten Komponenten angeboten.

:gruebel: Welche Komponenten meinst du? Ich kenne keine die SQL.Text nicht hat. (kommt ja aus der TStringList) Ich meinte aber nur das das wenigstens konsequent so oder so sein sollte:

Delphi-Quellcode:

ADOQuery1.SQL.Clear;
ADOQuery1.SQL.Add('select * from taccounts where susername='''+edit1.Text+''' and suserpass='''+edit2.Text+''' ');
...
ADOQuery1.SQL.Text:='INSERT into taccounts....

[sko1]

Wenn ich wissen will ob das Abfrageergebnis leer ist, habe ich noch nie EOF erwendet!

Bei mir tut es seit zig Jahren

Delphi-Quellcode:

...
ADOQuery.Open;
if ADOQuery.RecordCount = 0 then
  ShowMessage('Keine Daten gefunden');

Ciao
Stefan

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1368245)

Zitat:

Das scheint hier grundsätzlich so gelöst zu werden Query.SQL.Text wir wohl nur von den wenigsten Komponenten angeboten.

:gruebel: Welche Komponenten meinst du? Ich kenne keine die SQL.Text nicht hat.

Ich auch nicht, aber dieses

Delphi-Quellcode:

Query.SQL.Clear;
Qhery.SQL.Add('Select * ');
Query.SQL.Add('from My Table');

überlebt und überlebt und ......
Und jeder Anfänger übernimmt es......

Gruß
K-H

[haentschman]

Da sind wir uns mal einig...:thumb:

[nahpets]

Zitat:

Zitat von p80286 (Beitrag 1368250)

Zitat:

Zitat von haentschman (Beitrag 1368245)

Zitat:

Das scheint hier grundsätzlich so gelöst zu werden Query.SQL.Text wir wohl nur von den wenigsten Komponenten angeboten.

:gruebel: Welche Komponenten meinst du? Ich kenne keine die SQL.Text nicht hat.

Ich auch nicht, aber dieses

Delphi-Quellcode:

Query.SQL.Clear;
Qhery.SQL.Add('Select * ');
Query.SQL.Add('from My Table');

Oder wenn ich per ExecSQL 'ne Datenbankprozedure erstellen möchte:

Dann wird der Quelltext der Prozedur halt zeilenweise per SQL.Add übernommen.

überlebt und überlebt und ......
Und jeder Anfänger übernimmt es......

Gruß
K-H

Und als Fortgeschrittener nutze ich es auch.

Bei 'nem effen Select * from Tabelle mag Text ausreichen, aber bei etwas größeren und verschachtelten Statements ist eine (halbwegs) ordendliche Formatierung auch nicht zu verachten. Macht Statements irgendwie lesbarer.

Und in 'ner Fehlermeldung lässt sich so ein mehrzeiliges Statement deutlich besser lesen.

Delphi-Quellcode:

on e : Exception do begin
  MessageDlg('Fehler: ' + e.Message + #13#13 + qry.SQL.Text,mtError,[mbOk],0);
end;

hat dann durchaus schon was.

Etwas derartiges "http://www.delphipraxis.net/1367008-post24.html" könnte man natürlich als Einzeiler in SQL.Text pappen, aber wird das dann wirklich lesbarer und welchen Vorteil hat es, wenn man bei 'ner Stringliste immer nur Text nutzt?

Achja: Und wie macht ihr es, wenn ihr mal mit einem ExexSQL mehrere Statements an die Datenbank abgeben wollt?

Ich nehme dann für jedes Statement per SQL.Add eine Zeile, dann haben 50 Statements eben 50 Zeilen in der Stringliste. Klar, könnte man auch alles in 'ner Schleife per SQL.Text := SQL.Text + ' ' + NächstensStatement machen, aber ist da SQL.Add nicht irgendwie einfacher?

Irgendwie so:

Delphi-Quellcode:

qry.SQL.Clear;
qry.SQL.Add('create procedure PR_MD5_Dubletten_Verschieben as');
qry.SQL.Add('begin');
qry.SQL.Add('  insert into dubletten select * from tabelle where kategorie = ''MD5-Dublette'';');
qry.SQL.Add('  delete from tabelle where kategorie = ''MD5-Dublette'';');
qry.SQL.Add('end;');

Klar, könnte man auch so machen:

Delphi-Quellcode:

qry.SQL.Text('create procedure PR_MD5_Dubletten_Verschieben as begin insert into dubletten select * from tabelle where kategorie = ''MD5-Dublette''; delete from tabelle where kategorie = ''MD5-Dublette''; end;';

Aber erhöht das jetzt wirklich die Les- und Wartbarkeit?

Achso: Variable Inhalte füge ich per Format-Anweisung ein, und nicht wie im Beispiel als "festen Quelltext".
Und die Formatanweisung nutze ich nur, wenn aufgrund der Art des Statementes die Nutzung von Parametern nicht möglich ist. Dies ist z. B. dann der Fall, wenn eine Abfrage für unterschiedliche Tabellen genutzt wird oder, wie im Beispiel, Prozeduren erstellt werden, die (natürlich) über unterschiedliche Namen verfügen ...

[p80286]

Delphi-Quellcode:

const
  SQLTEXT='select feld1 '+
          '      ,feld2 '+
          '      ,feld3 '+
          'from tab1 join tab2 on (tab1.id=tab2.id and tab2.f7 is null) '+
          '          join tab2 t2 on (tab1.id=t2.id and t2.f3 is null) '+
          '          join (select myid from t5 where max(uptime)>25 Group by date) Timet on (timet.myid=tab2.id) '+ //da kann man bestimmt noch ein paar Zeilen reinquetschen.
          'where 1=1 '+
          '  and t2.feld4=''blödes hochkommagewurschtel'' '+
          '' ;

begin
  query1.close;
  query1.SQL.Text:=SQLTEXT;

so sehen die meisten meiner Abfragen aus. Einige wenige werden aus mehreren Teilen zusammen gesetzt, und einige enthalten Parameter.
Ich finde das übersichtlicher als im Quellcode eine Abfrage zusammen zu löten. Und diese Abfrage besteht nun mal aus dem ganzen Block und wird nicht aus mehreren teilen zusammen gestückelt.

Gruß
K-H

P.S.
Teilweise befinden Sie sich auch außerhalb des Programms. (Parameterdatei) Da finde ich es erst recht seltsam zeilenweise vorzugehen.

[Jumpy]

Ich lagere die SQl-Statements immer in Funktionen aus, da kann ich mir dann dort aussuchen, ob ich die von extern Lade oder im Quelltext zusammen baue.

Delphi-Quellcode:

procedure DeleteCurrentUser;
var q:TAdoQuery;
begin
  q:=TAdoQuery.Create(self);
  q.Connection:=Con;
  q.SQL.Text:=SQL_DeleteCurrentUser;
  try
    q.ExecuteSQL;
  finally
    q.free;
  end;
end;

function SQL_DeleteCurrentUser:String;
var s:TSQL;
begin
  s := TSQL.Create;
  s.Add := 'Delete From ' + TabelleUser;
  s.Add := 'Where ID = ' + CurrentID;
  Result:=s.Text;
  s.free;
end;

Für das Beispiel mal ohne Parameter. TSQL ist eine Stringlist mit ein paar Extras und .Add ist als Property angelegt, weil ich das mit den Klammern nicht so schön lesbar finde ".Add('Select...)".

[haentschman]

Moin...:P

Zitat:

Bei 'nem effen Select * from Tabelle mag Text ausreichen, aber bei etwas größeren und verschachtelten Statements ist eine (halbwegs) ordendliche Formatierung auch nicht zu verachten

...ja logisch. Ich spreche nur von der ersten Zeile...statt Clear+Add zu Text. :zwinker: Später heraus ist es legitim das Add, wegen der Formatierung, zu benutzen. :wink:

!!!Eigenwerbung: :wink:
@Jumpy, @p80286, @nahpets:
Früher habe ich auch die Statements im Quelltext angelegt. Die Statements waren nicht direkt 1:1 testbar (wegen Text, Add & Co.) Dann habe ich Ressourcen endeckt und komplett ausgelagert.
Tutorial:
http://www.delphipraxis.net/49505-sq...einbinden.html
SQLCreator:
http://www.delphipraxis.net/190316-d...e-creator.html

[nahpets]

Zitat:

Zitat von haentschman

!!!Eigenwerbung:

Hihi, kann ich auch:

Bei mir liegen für gewöhnlich alle Statements in eine Datenbanktabelle.

Lediglich das Statement zum Holen der Statements ist "fest verdrahtet".

Dadurch kann ich die Statements erstmal "ausprobieren". Jedes hat 'ne eindeutige ID, über die es angesprochen wird.

Parameter sind natürlich möglich, sowohl die SQL-Stringlistentypischen Doppelpunkt-Parameter, als auch die für ein Format erforderlichen %-Parameter. Selbst Kombinationen funktionieren.

Und bei 'nem Datenbankwechsel muss nur in dieser Tabelle die Syntax entsprechend den Anforderungen der Datenbank angepasst werden (soweit überhaupt erforderlich).

Typ(ück)isches Beispiel:

Delphi-Quellcode:

Select first 10 * from Tabelle

Delphi-Quellcode:

Select top 10 * from Tabelle

Delphi-Quellcode:

Select * from Tabelle where RowNum <= 10

Oder mal heißt es IsNull, dann mal IfNull oder Nvl oder Coalesce ...

Oder mal ||, um VarChars "zusammenzupappen" oder halt eben mit + ...

Wenn irgendmöglich, liegt das alles in der Datenbank und zwar so, dass es für das Programm absolut transparent ist.

"Datenbankwechsel?"
"Nagut, wenn Sie meinen. Daten in neue Datenbank kopieren, Tabelleninhalt anpassen und geht." (fast immer)

Bei mandandenfähiger Software ist es dann besonders schön, wenn für unterschiedliche Mandanten unterschiedliche Datenbanken genutzt werden, die Anwender aber nur eine Exe haben, die per Auswahldialog zwischen den Mandanten wechselt. Der Rest geht für Anwendung (und natürlich auch den Anwender) absolut transparent.

Zugegeben: Sowas musste ich bisher nur einmal bauen.