Tutorial Lazarus sqldb

[CCRDude]

Durch das Release von Lazarus 1.0 bin ich mal wieder angefixt worden, nachdem ich FreePascal nebenher schon seit Jahren verwende. Aktuell versuche ich ein kleines Nebenprojekt komplett in Lazarus zu entwickeln.

Unter Delphi habe ich auf MySQL und SQLite immer per Wrapper der DLLs sehr direkt zugegriffen; für die Platform- und Datenbankunabhängigkeit wollte ich unter Lazarus jetzt mal SQLdb verwenden.

Auf den Lazarus-Seiten gibt es diverse "Tutorials", die aber alle relativ mager sind. Klar, ich kann damit meinem TSQLQuery eine SQL-Anweisung verpassen und per Params.ParamByName().AsString etc. Werte zuweisen und über FieldValues auslesen, kann entsprechende INSERT und UPDATE-Queries setzen.

Aber: wenn ich das richtig verstanden haben, geht das doch eigentlich auch weniger "low level" (damit bekomme ich alles hin, was ich will, befürchte nur, damit "unnötigerweise" zu spezifisch für eine bestimmet DB zu sein), da gibt es ApplyUpdates, Edit, Post, InsertSQL, UpdateSQL, etc..

Gibt es beispielsweise Bücher/eBooks/PDFs zu sqldb bzw. dbExpress, an das das wohl stark angelehnt ist?

Die drei Wiki-Seiten im Lazarus-Wiki sind sehr unvollständig und für einen Einsteiger nicht wirklich zu gebrauchen. Insbesondere, da ich keine DB-Controls verwenden will, um diversen Units nicht Abhängigkeiten zu den Datenbankklassen aufdrücken zu müssen.

[p80286]

Ich vermute, da gibst Du dich falschen Hoffnungen hin.
Einmal abgesehen von der etwas verworrenen Erklärung zu (select)SQL,UpdateSQL,InsertSQL,deleteSQL , das dahinter liegende Prinzip ist eigentlich überall (Delphi und Lazarus / verschiedene DB) gleich.
in SQL.Text befindet sich das Select-Statement,
in Update.Text befindet sich das Update-Statement usw.
im nächsten Schritt übergibst Du Parameter (da ist die Syntax manchmal etwas abweichend) falls notwendig
Query.Params.Parameter[i].asstring:=MeinWert; dann erfolgt das .Open bzw das .ExecSQL falls es sich um ein Update-,Insert- oder Delete-Statement handelt.
Das Datenauslesen kennst Du ja schon, (jedenfalls hab ich es so verstanden)
bleibt nur noch die Transaktionssteuerung, die sich von DB zu DB unterscheidet.

Gruß
K-H

[CCRDude]

Hmmm.... ok, vielen Dank für die schnelle Antwort

Transaktionen werwende ich schon, auch Daten schreiben ist an sich kein Problem. Ich hatte halt die Hoffnung, dass es "schöner" (weniger SQL als spezielle Sprache im verwendenden Code) möglich wäre (über ein AutoParse-Property sollen doch beispielweise Queries automatisch generiert werden können?).

[p80286]

Zitat von CCRDude:

..(über ein AutoParse-Property sollen doch beispielweise Queries automatisch generiert werden können?).

Wenn ich jetzt wüßte worauf Du hinaus willst?
Bei Delphi/ADO habe ich die Möglichkeit mir die in einer DB vorhandenen Tabellen zu holen+vorhandene views. Damit könnte man ein wenig Rechtschreibprüfung treiben, aber spätestens bei den Aliasen ist dann schluß. Die Generierung muß aber dann scheitern, wenn es das gleiche Feld(namen) in unterschiedlichen Tabellen mit unterschiedlichen Inhalten gibt. Und wie will so ein Generator entscheiden ob ein einfacher oder ein left/right outer join die richtige Wahl ist.

Gruß
K-H

[CCRDude]

Worauf ich hinaus will? Nicht gleich ein ORM, aber ich hatte auf ein paar Erleichterungen gehofft, die es mir erleichtern, meinen Code von der verwendeten Datenbanktechnik zu abstrahieren, indem ein möglichst großer Teil der Datenbanklogik gleich dort bleibt.

Klar, dass JOINs nicht automatisch generiert werden können und auch besser gar nicht sollten, sagt mir schon die Erfahrung. Aber einfache INSERTs, UPDATEs und DELETEs auf eine Tabelle sollten sich doch "automatisch" anhand der Feldnamen und -definitionen erstellen lassen.

Ich hab in meinem aktuellen Spielprojekt, in dem ich u.a. dies ausprobiere, jetzt den Ansatz aus der anderen Richtung genommen. Eine einheitliche Struktur, die jeweils eine Tabelle beschreibt, und Code, der mir darauf basierend meine Standard-Queries baut und auch die Tabellenfelder analysiert und ggfls. aktualisiert. Also quasi aus der Notwendigkeit, dass ich diese Struktur eh brauche, um Tabellenupdates durchzuführen, die Tugend gemacht, mir meine Queries daraus erstellen zu lassen.

Wenn ich jetzt irgendwann noch viel Lust auf RTTI bekommen sollte, werd ich auch noch das Füllen/Auslesen der Daten automatisieren, aber nach RTTI steht mir der Sinn momentan noch nicht