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.

[haentschman]

Zitat:

Hihi, kann ich auch:

:P Der Möglichkeiten gib es verschiedene. Das Auslagern ist aus dem Quelltext ist das Entscheidende. :thumb:

PS: Bei deiner Variante hätte ich Bauchschmerzen immer an die Datenbank dran zu müssen. Beim Einspielen einer früheren Sicherung könnte die EXE nicht zu den Statements passen.

Wenn wir weiter darüber diskutieren wollen, sollten wir das in einen separaten Thread auslagern. :thumb:

[nahpets]

Zitat:

Zitat von haentschman (Beitrag 1368300)

PS: Bei deiner Variante hätte ich Bauchschmerzen immer an die Datenbank dran zu müssen. Beim Einspielen einer früheren Sicherung könnte die EXE nicht zu den Statements passen.

Richtig, und die übrigen Daten sind dann genauso veraltet.

Zuerst kommen die fertigen und durchgetesteten Statments in die Datenbank und dann die Daten.
Die erste Sicherung enthält damit immer die zur Datenbank passenden Statements. Eine veraltete Version gibt es nicht (es sei denn, irgendwer daddelt später noch an den Statements rum. Der bekommt dann aber Haue).
Davon abgesehen werden die Statements immer auch noch als Scripte zu den Quelltexten der Software gelegt (und ggfls. damit zusammen versioniert).

Ok, das ist ein vielfältiges Thema, über das man andernorts sicherlich mal 'ne "Grundsatzdiskussion" führen könnte, um ggfls. aus den bisher "erfundenen" Konzepten ein "allumfassendes" zu machen, das alle Vorteile der bisherigen Konzepte vereinigt und alle Nachteile ebendieser eleminiert.

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1368295)

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

Im Prinzip gefällt mir der Ansatz, nur der Zugriff über die wenig sprechende ID gefällt mir nicht. Aber bei deskriptiv hat wieder jeder andere Ideen.

Gruß
K-H

[nahpets]

Die ID schien mir das Sinnvollste für den Zugriff aus 'nem Programm zu sein.

In der Datenbanktabelle steht neben ID und SQL auch noch 'ne Beschreibung zum SQL, so dass man dort auch noch Sinn und Zweck nachlesen kann, ohne erstmal das Statement zu analysieren.

Im Programmquelltext steht an den Stellen, an denen ein Statment aus der DB geholt wird, immer auch ein entsprechender Kommentar (soweit sich nicht aus dem Quelltext bereits ein eindeutiger Hinweis ergibt).

Ein

Delphi-Quellcode:

qry.SQL.Text := GetSQLStatement(42);
qry.Open;
...

ist ein absolutes NoGo.

Entweder das ist in einer Prozedur oder Funktion mit einem sprechenden Namen gekapselt oder davor steht ein Kommentar.

Mindestens

Delphi-Quellcode:

// vollständige Lieferantenliste anzeigen.
qry.SQL.Text := GetSQLStatement(42);
qry.Open;
...

Für jemanden, der den Quelltext erstmalig liest, dürfen keine Fragen offen bleiben.

Wenn der erst in der Datenbank nachschauen muss, was für ein Statment denn da geholt wird, ist etwas grundlegend falsch.

[p80286]

Wie wäre es mit

Delphi-Quellcode:

const
  GETPERSONLIST=42;

.....
qry.SQL.Text := GetSQLStatement(GETPERSONLIST);
qry.Open;
 ...

Gruß
K-H

[nahpets]

Klar, kann man so machen.

Habe da mal 'ne eigene Klasse, abgeleitet von einer Datenbankkomponente gemacht. Die Klasse hatte u. a. die Attribute InsertID, UpdateID, DeleteID und SelectID. Dort stand dann die entsprechende ID.

Dann gab es die passenden Methoden dazu.

Von dieser Klasse waren dann die weiteren Klassen für Kunden ... abgeleitet. Sie hatten zusätzlich dann die entsprechend Attribute wie Name ...

Als Programmiere musste man für's Select dann nur noch die Get-Methode aufrufen. Für neue Daten halt New, Update ging über Set und Delete setzte nur einen Löschschalter und Löschdatum ... im Datensatz, da keine Daten physikalisch aus der Datenbank entfernt wurden.

Eigentlich war das für den Entwickler sehr transparent.

Er musste sich weder um die Zuweisung der Tabelleninhalte in die Attribute kümmern, noch um den umgekehrten Weg.

Das Einzige, was er machen musste, war: Die Inhalte der Attribute in die Anzeigemaske bringen bzw. die Inhalte der Anzeigemaske wieder in die Attribute der Klasse schieben.
Dafür waren die passenden Getter und Setter angelegt.
Und er musste natürlich, soweit erforderlich, die entsprechende Geschäftslogik und ggfls. Plausibilitätsprüfungen ..., implementieren.

Die Basisklasse war schon recht kompliziert und funktionierte zum Teil über RTTI, aber die Benutzung im Programm war dann beinahe schon banal einfach.

Schon interessant, was man mit RTTI und sinnvoller Vererbung für "schöne Schweinereien" machen kann. Da sieht man dann, wie leistungsfähig einen vernünftige Objektorientierung sein kann.

[p80286]

Die eigene Klasse liegt eigentlich früher oder später auf der Hand (DataModule). Aber wo kommt da RTTI in Spiel?

Gruß
K-H

[nahpets]

Die Klassen haben halt mehr oder weniger Attribute, die sich entsprechend in der Datenbanktabelle wiederfinden.

Über Namenskonventionen findet ein Mapping statt, so dass es nicht erforderlich ist, in den Statements für jede Klasse die Spalten und Wherebedingung für die Schlüsselspalten anzugeben. Dies wird alles zur Laufzeit von der Klasse über RTTI automatisch "geregelt".

Leider hab' ich keinen Zugriff mehr auf die Quellen, die sind bei 'nem ehemaligen Arbeitgeber entstanden, der inzwischen nicht mehr existiert.
Und an die genauen Details kann ich mich nicht mehr so wirklich erinnern (ist ca. 10 Jahre her), dafür war das dann doch etwas zu kompliziert, um es aus dem Stehgreif rekonstruieren zu können.

[xReva]

Danke für all die Hilfe ich habe es jetzt hinbekommen :)


Mfg Lucas

[haentschman]

:P Und wie sieht das Ergebnis aus?