Umfrage: Beispiele mit Datenbanken

[af0815]

Ich verwende sowas für den MS-SQL Treiber. Läuft unter Win10/64, Debian 64 (verschiedene Versionen) und RasPi (32 Bit). Absolut wichtig bei SQLDB ist, das du den Pfad zur Lib nur dann setzen kannst, wenn die Connection noch nie geöffnet/verwendet wurde. Deswegen wird die hier dynamisch erzeugt und später erst an die Queries etc. gebunden. Wenn man ganz tief in die SQLDB eintaucht, so sieht man das der Treiber eine globale Variable ist, die vor der Initialisierung des Treiber ermittelt wird, außer man setzt die auf den gewünschten Wert. Das ist zumindest beim MS-SQL Treiber so. Ich gehe davon aus, das das bei anderen Treibern ähnlich gehandhabt wird.

Code: Alles auswählen

procedure TDMSql.DataModuleCreate(Sender: TObject);
begin
  {$ifdef SQLDebug}DebugLn({$I %FILE%} + '->' +{$I %CURRENTROUTINE%} +' start');{$endif}
  try
      // Muss hier VOR dem Erzeugen der Connection stehen !!
     {$ifdef Unix}
       {$ifdef RasPi}
         DBLibLibraryName := 'libsybdb.so.5';
       {$else}
         DBLibLibraryName := '/usr/lib/x86_64-linux-gnu/libsybdb.so.5';
       {$endif}
       {$else}
         DebugLn({$I %CURRENTROUTINE%} +' Using Windows Connection');
         DBLibLibraryName := 'sybdb';
      {$endif}
     DebugLn({$I %CURRENTROUTINE%} +' -> DBLibLibraryName = ' + DBLibLibraryName);
     SQLCon := TMSSQLConnection.Create(self);
     // Mssql
     SQLTransaction:= TSQLTransaction.Create(SQLCon);
     SQLCon.Transaction := SQLTransaction;
     SQLCon.CharSet:= 'UTF8';
     SQLCon.Options:=[scoApplyUpdatesChecksRowsAffected];
     // common part
     SQLCon.UserName := coUser;
     SQLCon.Password := coPassword;
  finally
     //
  end;
  {$ifdef SQLDebug}DebugLn({$I %FILE%} + '->' +{$I %CURRENTROUTINE%} +' end');{$endif}
end;

Nachdem der Code seit Jahren bei mir läuft habe ich mir den TSQLLibraryLoader noch nicht angesehen, werde ich aber mal auf meine ToDo Liste setzen. Wenn der seine Mitarbeit verweigert, so würde ich es nach obigen Gesichhtspunkten mal machen. Alles zur Laufzeit erzeugen und die Connection ganz zum Schluss erst. Wenn der so arbeitet wie ich vermute, kann der nach dem Initialisieren des Treibers die Library nicht mehr ändern.

[Socke]

Weil die TSQLite3Connection keine Möglichkeit der Zuweisung der sqlite3.dll hat habe ich einen TSQLLibraryLoader benutzt der seine Mitarbeit verweigert und friert denk ich den Debugger oder Lazarus ein.

weder .Enabled noch .LoadLibrary bringts. Beides friert Lazarus ein. Sieht irgendwie nach einer Endlosschleife aus die ich nicht finde. Die scheint aber nicht bei mir zu liegen denn zb einfach .Enabled auf true setzte dürfte kein freeze auslösen.

Du musst erst den ConnectionType und dann den Pfad zur Bibliothek angeben. Bei Änderung des ConnectionTypes wird die Standardbibliothek aus der Connection-Definition gesetzt.
Wie du versuchst, den korrekten Dateinamen zu raten ist mir aber nicht wirklich verständlich.

[af0815]

weder .Enabled noch .LoadLibrary bringts. Beides friert Lazarus ein. Sieht irgendwie nach einer Endlosschleife aus die ich nicht finde. Die scheint aber nicht bei mir zu liegen denn zb einfach .Enabled auf true setzte dürfte kein freeze auslösen.

Bin verwirrt und bitte um Hilfe ... vielleicht kann sich auch jemand aus dem Linuxlager das Teil ansehen. besonders die Suchpfade müssten mit defines angepasst werden. Linux ist jetzt nicht meine Hauptwelt.

Ich habe da noch keine Probleme mit dem Beispiel gesehen, abgesehen davon, das ich den Aufbau der DB nicht kenne und auch keine dabei ist. Ausserdem kann ich bei der demo.sql auch nur raten. Ich nehme an, dadrinnen steht die definition, wie die Tabellen erstellt werden sollen bzw. ein paar Daten eingefügt werden.
Aber bei mir gab es nur eine (gewollte) Exception weil die demo.sql fehlt.

Fur mich ist der TSQLLibrayLoader mal interessant, den kannte ich noch nicht. Das mit dem FileRaten ist nett. Einfach in den Verzeichnissen suchen. die über den Parameter sWhereToSearch angegeben sind, ab dem aktuellen Verzeichnis. Das mit dem ApplicationLocation würde ich mir überlegen, weil in den Betriebssystemen davon auszugehen ist, das das Programm und die Daten an unterschiedlichen Bereichen untergebracht sind. Wenn du unter Windows richtig arbeitest, so kann der Benutzer im Programmdirectory nicht schreiben und sollte dem vom System mitgeteilten Pfad verwenden. Ist unter Linux auch so, wenn man sauber installiert und sich die mühe macht einen Installer zu bauen.

[charlytango]

Du musst erst den ConnectionType und dann den Pfad zur Bibliothek angeben. Bei Änderung des ConnectionTypes wird die Standardbibliothek aus der Connection-Definition gesetzt.
Wie du versuchst, den korrekten Dateinamen zu raten ist mir aber nicht wirklich verständlich.

Ich hab also getestet:
A: zuerst den ConnectionType angeben, dann den LibraryName zuweisen
B: ConnectionType nicht mehr zuweisen (wurde schon in der GUI eingestellt) und nur den LibraryName zuweisen

Beide Fälle mit Enabled:=true
und dann noch beide Fälle mit LoadLibrary anstelle Enabled:=true

alle 4 Testfälle f+ühren dazu dass Lazarus hängt und nur per Taskmanager zu killen ist.
Auch der Debugger lässt sich nicht abschalten.

[af0815]

Nachdem es bei mir ohne viel Probleme geht. Hast du eine db und das sql-Script für mich zum testen ? Oder baut das SQL-Script die DB ?!

Ich habe bisher keinen Hänger oder ähnliches gehabt mit deinem Beispiel. Auch Lazarus mit dem Debugger läuft komplett rund.

[charlytango]

Alles zur Laufzeit erzeugen und die Connection ganz zum Schluss erst. Wenn der so arbeitet wie ich vermute, kann der nach dem Initialisieren des Treibers die Library nicht mehr ändern.

In meiner grenzenlosen Naivität dachte ich dass man so ein zur Verfügung gestelltes Datenmodul nicht nur für Beispielprojekte verwenden kann sondern auch als Datenmodul für Anfänger und GUI-Nutzer die ja eine Komponente brauchen zu der sie eine TSQLQuerty verbinden können.

Dass das Teil bei dir läuft verwundert mich etwas. Mit 2.2.4 (32 bit) getestet und das gleiche Ergebnis. Irgendwie scheint Lazarus einzufrieren oder in einer Schleife zu laufen.

Ein eigenes SQL-Script/file hab ich noch nicht. Allerdings hab ich zwei klassische Demodatenbanken gefunden die für SQLite adaptiert wurden (GitHub). Zip liegt bei

Dem Thema ApplicationLocation würde ich mich im Nachgang nähern, bin da keineswegs beratungsresisten.

Eine Version mit zur Laufzeit erstellter Zugriffskomponente kann ich auch nochmal probieren.
Sollte es aber so dein wie du meinst, dass ein Treiber nicht erneut zuzuweisen ist, frage ich mich wie das mit den Vordefinerten Komponenten in einem Formular ist -- wann werden die created? Denn dann hätte ich evtl mit dem Konzept schlechte Karten

[af0815]

In meiner grenzenlosen Naivität dachte ich dass man so ein zur Verfügung gestelltes Datenmodul nicht nur für Beispielprojekte verwenden kann sondern auch als Datenmodul für Anfänger und GUI-Nutzer die ja eine Komponente brauchen zu der sie eine TSQLQuerty verbinden können.

Wenn man ganz naiv ist, so nimmt man die sqlite3.dll und kopiert man sowohl in das Lazarus Verzeichnis als auch in das Verzeichnis wo die exe vom Projekt ist und gut ist es. Außer man hat die falsche Bitness (32/64 bit) erwischt Leider ist es so, das meiner Erfahrung nach alle Versionen der SQLite dll gleich heissen.

Dann hängt man seine Komponenten zusammen und es geht. Wenn man anfängt mit Tricks zu arbeiten dann wird es komplizierter.

Meiner Meinung nach gehören die dll's in die richtigen Systemverzeichnisse, ich habe aber nur noch keine saubere Version gesehen, wie ich die dort unterbringe, so das sie von Lazarus oder meinem Programm gefunden werden. Und zwar unabhängig davon ob mein Programm/Lazarus 32 oder 54 Bit ist.

Unter Linux sollte SQLite 'out of the box' gehen. Ich habe meine Focus allerdings mehr auf den MS-SQL gelegt, da ich den beruflich brauche und zwar auf fast allen Plattformen.

EDIT: Zum Nachlesen, damit wir hier nicht alles neu erfinden: viewtopic.php?f=55&t=14050

[charlytango]

Danke... nur kurz Zwischeninformation.
Ich hab mit viel Begeisterung eine uralte sqlite.dll verwendet die irgendwo in den tiefen meines Rechners herumkrebste. Kaum hab ich die aktuelle verwendet klappte es sofort mit dem Zugriff.
Den Wald vor lauter Bäumen nicht gesehen.

Ich schnitze aber weiter an dem Konzept, etwas Geduld noch.

[charlytango]

nun denn...
Es existiert ein Testprojekt in dem ich drei verschiedene Arten eingebaut habe eine (SQLite) Datenbank anzusprechen. Basisziel ist es, Erstellern von Demos/Beispielen mit DB-Zugriff ein Werkzeug in die Hand zu geben das sich um alles kümmert was nicht das eigentliche Beispiel betrifft.

1 SQLdbGUI
Zielgruppe -> Beispielersteller die ein Datenmodul brauchen um ihre Abfragen zu verbinden.
Ein komplexeres Datenmodul. Automatische DB-Erstellung, Suche nach DDL/so, manueller und automatischer Import eines .SQL Files um für das Beispiel immer wieder die gleichen Daten fürs Beispiel zu haben.
Der Beispielersteller muss nur das .SQL File zur Verfügung stellen. Ein standard.sql für eine Demodatenbank liegt auch bei. Diese könnte man ggfs auch für unterschiedliche Zwecke erweitern. Zugriffskomponente: TSQLConnector

2 SQLdbSimple
Ein einfaches Datenmodul. Datenbanknamen anpassen und verwenden. Keine besonderen Funktionen, nur eine Import-Funktion zum Bestücken der DB. Zielgruppe->Beginner (wegen des schnelleren Erfolges). Zugriffskomponente: TSQLite3Connection

3 SQLdbRuntime
KEIN Datenmodul sondern "nur" eine Klasse über die alles genauso wie bei SQLdmGUI funktioniert, aber kein Datenmodul ist. Alle nötigen Komponenten/Objekte werden zur Laufzeit erzeugt. Funktion gleich wie SQLdbGUI. Zugriffskomponente: TSQLConnector

Die Varianten 1 und 3 können mittels Define-Switches an unterschiedliche Anforderungen angepasst werden. Ein beiliegendes Include-File regelt über Konstanten Namen und Bezeichnungen. Daher sind diese Varianten auch für serverbasierte DBs verwendbar.

Ich bitte erstens mal um Hilfe das Konzept und die Umsetzung zu testen und ggfs auseinander zu nehmen
Das Teil kann nur Aussicht auf Erfolg haben wenn es solide ist und Erstellern von Demos Zeit spart und Funktion bietet.

SQLdbSimple funktioniert klaglos

SQLdbGUI klappt auch.

SQLdbRuntime: hier wird der DB-Zugriff gemacht, der Import/Query klappt nicht ob wohl ich Stein und Bein schören könnte dass die Variante gleich wie SQLdbGUI ist nur als Runtime. Exception: database not assigned. Bin überzeugt ich habe die DB zugewiesen, denn der Connect zur DB klappt ja.
Offensichtlich nicht -- ich finde den Unterschied leider nicht -- von daher brauchts Hilfe.

Zudem gibt es noch eine Auffälligkeit bei SQLdbGUI und SQLdbRuntime (bei SQLdbSimple klappt es):
Beim Workflow: Zugriff erzeugen, Importieren, Query starten -- und erneut Importieren wird gemeckert:
TSQLite3Connection: database table is locked
Offensichtlich schalted der TSQLconnector auf die TSQLite3Connection um und irgend etwas scheint da nicht korrekt eingestellt zu sein. Also auch hier bitte Hilfe.

THX

[af0815]

Zum Demoprojekt

a ) Erstelle einmal im Projekt die Buildmodes für Debug und Release

b ) Versuch mal das Projekt zu kompilieren im Debugmodus


Warum a : Damit man Fehler beim entwickeln schon mal sieht und das du durch das Programm auch wirklich durchsteppen kannst.
Warum b: Weil durch a einiges sichtbar wird. (BTW: ein Klassiker)

Nicht ganz optimal, man muss das Programm 2x starten, weil beim ersten mal wird die DB nicht gefunden (aber angelegt) erst beim 2ten mal ist die DB mal vorhanden. Da ich den Spaß kenne, weis ich warum das so ist Das Verhalten von SQLite is je nach Standpunkt gut oder schlecht.

Edit: Statt dem writeln in DoSQLLog würde ich da den LazLogger verwenden. Und kein ZEOS als Required Package. Ich will ohne Änderung das Beispiel testen.

Edit2: Nachdem das Importscript bei mir nicht durchläuft breche ich mal ab (TSQLite3Connection : near "NO":Syntax error)

[charlytango]

Nicht ganz optimal, man muss das Programm 2x starten, weil beim ersten mal wird die DB nicht gefunden (aber angelegt) erst beim 2ten mal ist die DB mal vorhanden. Da ich den Spaß kenne, weis ich warum das so ist Das Verhalten von SQLite is je nach Standpunkt gut oder schlecht.

man muss nicht nochmal starten -- es wird zwar eine Meldung angezeigt aber trotzdem eine DB je nach Einstellungen im include file erzeugt. die ist dann auch benutzbar weil dazu auch connected wird.

Welche der drei Varianten hast du getestet? das sind alles unterschiedliche Module

[charlytango]

Zum Demoprojekt

a ) Erstelle einmal im Projekt die Buildmodes für Debug und Release

b ) Versuch mal das Projekt zu kompilieren im Debugmodus

Hab ich gemacht und mit Debug Modus neu kompiliert. Danke für den Hinweis.
Trotzdem kann ich in in den SQLdb Dateien keinen Breakpoint setzen, da schein noch was zu fehlen

Edit: Statt dem writeln in DoSQLLog würde ich da den LazLogger verwenden. Und kein ZEOS als Required Package. Ich will ohne Änderung das Beispiel testen.

ZEOS als Package nehme ich raus, die Logvariante war bloss so eine Idee, aber der Hinweis mit LazLogger macht Sinn

Edit2: Nachdem das Importscript bei mir nicht durchläuft breche ich mal ab (TSQLite3Connection : near "NO":Syntax error)

Hab beim Import nur beim runtime modul Probleme, die anderen beiden sollten klappen.
versuch SQLdbSimple, da sollte Import klappen. welche sqlite.dll oder so verwendest du ich hab hier 3.39.4?

[af0815]

Edit2: Nachdem das Importscript bei mir nicht durchläuft breche ich mal ab (TSQLite3Connection : near "NO":Syntax error)

Hab beim Import nur beim runtime modul Probleme, die anderen beiden sollten klappen.
versuch SQLdbSimple, da sollte Import klappen. welche sqlite.dll oder so verwendest du ich hab hier 3.39.4?

Es macht bei allen drei Varianten denselben Error. Ich würde da mit einem kleinen Basic Script anfangen und nicht gleich einen solchen Moloch.

[shokwave]

Meiner Meinung nach gehören die dll's in die richtigen Systemverzeichnisse, ich habe aber nur noch keine saubere Version gesehen, wie ich die dort unterbringe, so das sie von Lazarus oder meinem Programm gefunden werden. Und zwar unabhängig davon ob mein Programm/Lazarus 32 oder 54 Bit ist.

Ich glaube da kann ich helfen.
Die 64Bit-dll gehört in "Windows\System32" und die 32Bit-dll in "Windows\SysWOW64".
Auf einem 32Bit-Windows sind im System32 32Bit-Dlls und auf einem 64Bit-Windows 64Bit-Dlls. Das Verzeichnis wurde, vermutlich aus Kompatibilitätsgründen, beim Wechsel auf 64Bit nicht umbenannt.
Dafür wurde das SysWOW64-Verzeichnis erfunden, welches dann für architekturfremde(sprich 32Bit-) Programme die Bibliotheken enthält. Das "WOW64" steht für "Windows(32Bit-Programm) On Windows64(Bit)".

[af0815]

Probiert auch ? Oder nur wissen ?