Datenbankzugriff in Lazarus - eine Odyssee!?

Für Fragen von Einsteigern und Programmieranfängern...
Michel
Beiträge: 35
Registriert: Sa 4. Dez 2021, 11:43
OS, Lazarus, FPC: Windows 10 / Ubuntu 20.04 LTS (L 2.0.12 FPC 3.2.0)
CPU-Target: 64Bit

Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Michel »

Hallo zusammen!

Es mag sein, dass diese Frage nicht unter "Einsteigerfragen" gehört. Aber da ich derzeit an grundlegenden Versuchen scheitere, irgendwie auf eine Datenbank, sei MySQL oder SQLIte3 zuzugreifen, fehlt mir wohl irgendein Verständnis, das ich auch nach stundenlangem Try-and-Error und Quälen der Suchmaschine nicht finde.

Ich fange mal mit SQLite3 an, da ich hier auf einem Ubuntu-PC einfach nur eine Installation der Datenbanksoftware und zusätzlich ein grafisches Administrationswerkzeug installieren muss. Die Software ist installiert, mit dem grafischen Werkzeug kann ich völlig ohne Probleme eine Datenbank und eine Tabelle erstellen und sogar mit Daten füllen.
Die Runtime-Bibliothek ist auch verfügbar: /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
Zusätzlich gibt es einen symbolischen Link hierzu: /usr/lib/x86_64-linux-gnu/libsqlite3.so.0

Nun das Ganz in Lazarus. Ich nutze die grafischen Komponenten TSQLite3Connection, TSQLTransaction, TSQLQuery, TDataSource und einen TDBGrid und TDBNavigator. Trage hier die passenden Daten ein, bzw. wähle dies einfach aus, soweit so gut. Beim Klick auf "Connected" in der TSQLite3Connection erhalte ich direkt die Meldung "Can not load SQLite client library "libsqlite3.so". Check your installation.".

Es folgt eine vergebliche Suche nach der Ursache. Scheinbar fehlt ein Link, der nicht /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 sondern /usr/lib/x86_64-linux-gnu/libsqlite3.so heißen muss. Kann man irgendwie hinfummeln, aber das erschwert die Portierung bereits auf identische Systeme. Nun, da gibt es die Komponente TSQLLibraryLoader, schnell eingebaut und unter Libraryname "libsqlite3.so.0" eingetragen, enabled und voìla, die übrigen Komponten können allesamt aktiviert werden, mit dem Effekt, dass in der Designansicht, man wie unter Delphi gewohnt, in den Komponenten eine Voransicht der Daten in der Tabelle sieht. F9 drücken, und dann erneut Meldung "Can not load SQLite client library "libsqlite3.so". Check your installation.". Ich habe dann die Runtime-Bibliothek /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 direkt mit dem Namen libsqlite3.so einfach einmal in das Programmverzeichnis kopiert, bringt rein gar nichts. Es mag daran liegen, dass ja der TSQLLibraryLoader, der ja aktiv ist, doch noch irgendwie genutzt wird.

Dann kommt der Versuch, in den grafischen Komponenten das richtig zustellen. Zunächst gibt es bei jedem Wechsel von Datenbank-Komponeten von active auf inactive eine MessageBox (Access Violation). Mein Versuch den TSQLLibraryLoader wieder inaktiv zu setzen, um z.B. beim Create die Aktivierung manuell vorzunehmen, wird mit einem Fehler Kann Form1 nicht streamen: TForm1
Access violation

Pfad zur fehlgeschlagenen Instanz
TForm1.SQLQuery1

quitiert. Einzig mögliche Maßnahme, die IDE ohne Speichern beenden.

Diese Access Violation (allerdings nur diese Meldung ohne Ausstieg und scheinbar ohne Wirkung) erhalte ich außerdem beim Toggeln der activity der DB-Komponeten. Dieses Verhalten der IDE, d.h. im Designer läuft der Zugriff auf die DB und ausgeführt nicht (ohne jegliche Fehlermeldung, DBGrid scheinbar inaktiv gesetzt), ist auch beim Test mit MySQL gleich. Hie wird allerdings kein Fehler, sondern nur ein inaktives Grid angezeigt.

Natürlich habe ich neu die IDE neu installiert und jegliche Installation von weiteren Addons unterlassen, um eben das Problem zu lokalisieren.

Dann finde ich es auch merkwürdig, wenn in der IDE in dem jeweiligen Object-Explorer bei Werten aus einer Liste die Werte scheinbar in der Hintergrundfarbe dargestellt werden (also unsichtbar) sind, und erst wenn man mit den Pfeiltasten blättert, zumindest die einzelnen Werte sicht- und auswählbar werden. Aber das ist ein anderer Punkt.

Also, ich habe einige Jahre Programmiererfahrung mit Delphi bis 7 für das gute alte WindowsXP. Ich bin also mit der hier "nachgebildeten" IDE schon vertraut. Ich bin doch sehr überrascht über diese schon sehr massiven Probleme in der letzten als stable markierten Version von Lazarus und denke noch, dass ich einfach zu blöd bin, die IDE korrekt zu bedienen. Daher mein verzweifelter Hilferuf an dieser Stelle.

Michel
Beiträge: 35
Registriert: Sa 4. Dez 2021, 11:43
OS, Lazarus, FPC: Windows 10 / Ubuntu 20.04 LTS (L 2.0.12 FPC 3.2.0)
CPU-Target: 64Bit

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Michel »

Ergänzung zum Thema Lazarus und mitgelieferte grafische Komponenten für SQlite3:

Scheinbar nutzen viele eine alternative Bibliothek für die Datenbankentwicklung, hier ZEOS.

Folgender Code ermöglicht den Zugriff auf die Datenbank, wobei die SQLite3 Bibliothek sich im Programmpfad befindet. Allerdings wird beim Compilieren als veraltet moniert und ist so nicht plattformübergreifend nutzbar.

Code: Alles auswählen

procedure TForm1.FormCreate(Sender: TObject);
begin
  SQLiteLibraryName:='./libsqlite3.so';
  SQLite3Connection1.Connected:=True;
  SQLTransaction1.Active:=True;
  SQLQuery1.Active:=True;
end;
unit1.pas(41,20) Warning: Symbol "SQLiteLibraryName" is deprecated: "use sqlite3dyn.SQLiteDefaultLibrary instead"

Folgt man diesem Krumen, stößt man auf sqlite3conn.pp. Aber ein alternatives SQLite3Connection1.LoadExtension('./libsqlite3.so') geht ins Leere. Witzigerweise wird vorausgesetzt, dass die Connection aktiv ist. Es mag sein, dass ich den Sinn nicht zu erfassen mag.

Also, dann manuell eine symbolische Verknüpfung. Dann geht es auch ohne die veraltete Variable.

Code: Alles auswählen

sudo ln -s /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 /usr/lib/x86_64-linux-gnu/libsqlite3.so
Das ist leider keine wirklich saubere Lösung, vor allem wenn es beliebig portiert werden soll.

Zurück zu der Lösung, eine Kopie der Laufzeitbibliothek in das Programmverzeichnis abzulegen und zu nutzen. Hier stößt man auf ein tückisches Linux-spezifisches Detail. Ein vorangestelltes "./" sorgt dafür, dass im Verzeichnis geschaut wird, aus dem das Programm aufgerufen wird. Ich muss hier wohl nochmal nach den speziellen Funktionen schauen, die das automatisch regeln. Aber ein Eintrag via grafische Komponente scheidet demnach aus. Mir wird so langsam klar, dass dies wohl sämtliche grafischen Komponenten betrifft, die Pfadangaben enthalten.

Nachfolgender Code stellt (auf einem Linux-System) sicher, dass die Verbindung via im Programmverzeichnis enthaltene Laufzeitbibliothek für SQLite3 erfolgt. Damit ist das Programm vom Prinzip her portabel. Ich meine verstanden zu haben, dass dieser Binärcode sich nur bzgl. 32Bit oder 64Bit unterscheidet, so dass ein Umbenennen in .dll ausreicht, um auch in Windows zu laufen.

Code: Alles auswählen

procedure TForm1.FormCreate(Sender: TObject);
begin
  SQLDBLibraryLoader1.LibraryName:='./libsqlite3.so';
  SQLDBLibraryLoader1.Enabled:=True;
  SQLite3Connection1.Connected:=True;
  SQLTransaction1.Active:=True;
  SQLQuery1.Active:=True;
end;
Puh, da steht mir ja noch was vor.

Carsten1975
Beiträge: 23
Registriert: Mi 4. Apr 2018, 18:22

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Carsten1975 »

Also ich habe schon sehr viele Datenbanken in meinen letzten 30 Jahren genutzt und auch viele Daten von der einen auf die andere portiert.

Egal ob das MS-SQL, Lotus Notes, DB2, SAP-DB, Cache, Oracle, Access, FoxPro, MySQL, PostgreSQL oder MariaDB war. Ich für meinen Teil muss ganz ehrlich sagen ich verwende seit über 20 Jahren erst MySQL und nachdem Oracle die Nutzungsbedingungen geändert hat, nur noch MariaDB. Sie ist kostenlos, bietet sogar einen deutschen Support (Firmensitz in München) und ist mittlererweile besser als MySQL. Und wenn man sich anschaut, dass Wikipedia, Amazon, Google, Booking.com und viele andere großen Firmen, die sich auch kostenpflichtige Datenbanken leisten können, diese Datenbank benutzen mit einem kostenpflichtigen Support, dann spricht vieles für diese Datenbank.

Wer jetzt mit Datenbanken anfängt, dem kann ich als DB-Spezialist nur MariaDB oder als weitere alternative PostgreSQL ans Herz legen. Wobei PostgreSQL doch diverse tücken im Gegensatz zu MariaDB hat.

Und was MySQL betrifft, so fragen sich viele warum diese Datenbank nicht mehr so stark verbreitet ist und immer mehr auf MariaDB wechseln?

Oracle hat das schwedische Open-Source-Unternehmen übernommen und dann nach mehreren Jahren (im Jahre 2016) die Lizenz zur kostenlosen Nutzung mit der Version 5.6 geändert. Diese besagt, wer weiterhin die Datenbank kostenlos nutzen will muss den gesamten Quelltext des Programmes, das die Datenbank nutzt, an Oracle weitergeben und somit auch das Copyright-Recht.

Ich habe nur positive Erfahrungen mit MariaDB gemacht und es funktioniert auch problemlos in Lazarus.

Michel
Beiträge: 35
Registriert: Sa 4. Dez 2021, 11:43
OS, Lazarus, FPC: Windows 10 / Ubuntu 20.04 LTS (L 2.0.12 FPC 3.2.0)
CPU-Target: 64Bit

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Michel »

Nachtrag:

Also, sofern man die visuellen Komponenten nutzen mit einer aktiven Verbindung zur Datenbank nutzen möchte, muss man in der SQLDBLibraryLoader1.LibraryName den kompletten Pfad zur Laufzeitbibliothek eintragen. Allerdings läuft mal eben debuggen mit F9 wieder auf den Fehler "Can not load SQLite client library "libsqlite3.so". Check your installation.", weil der Formular.Create später als die im Formular enthaltenen Objekte ausgeführt wird. Ist ja irgendwie logisch, aber hier fatal, weil hier bereits auf eine Laufzeitbibliothek zugegriffen wird, die ja erst später dazu geladen wird. Der Fehler dürfte aber auch sein, dass bei Programmstart dem Connect-Objekt vor dem SQLDBLibraryLoader bei der Instantierung warum auch immer der Vorzug gegeben wird und dann der (ungültige) default-Wert genutzt wird. Während des Designs stelle ich ja sicher, dass zuerst der SQLDBLibraryLoader erfolgreich aktiviert wird. Dürfte ein bug sein. Oder hat jemand eine Idee, ob und wenn wie ich die Reihenfolge der zu instantiierenden Objekte beeinflusse kann.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6209
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von af0815 »

Ich kenne solche Probleme mit den Treibern unter Linux nicht (Debian) und ich verwende SQLDB statt ZEOS, damit ich nicht von externen Komponenten abhängig bin.
Grundlegend muss die Bibliothek 2x gefunden werden. 1x von Lazarus für die Designzeit und 1x zur Laufzeit vom kompilierten Programm. Der Symlink auf die libsqlite3.so sollte bereits von System richtig angelegt sein. Unter Linux sollte ein herumgemurkse nicht notwendig sein und vor allen kein "./libsqlite3.so".
Allerdings muss ich sagen, das ich seit längeren nichts mit sqlite gemacht habe, sondern mit anderen DB.

Aber hast du die -dev Pakete von sqlite3 auch installiert ? Sieh auch https://forum.lazarus.freepascal.org/in ... pic=9484.0
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Michel
Beiträge: 35
Registriert: Sa 4. Dez 2021, 11:43
OS, Lazarus, FPC: Windows 10 / Ubuntu 20.04 LTS (L 2.0.12 FPC 3.2.0)
CPU-Target: 64Bit

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Michel »

Carsten1975 hat geschrieben:
Do 6. Jan 2022, 16:40
...
Wer jetzt mit Datenbanken anfängt, dem kann ich als DB-Spezialist nur MariaDB oder als weitere alternative PostgreSQL ans Herz legen. Wobei PostgreSQL doch diverse tücken im Gegensatz zu MariaDB hat.
....
Ich habe nur positive Erfahrungen mit MariaDB gemacht und es funktioniert auch problemlos in Lazarus.
Dem kann ich nur voll und ohne Abzug zustimmen. :) Aber ich versuche gerade, Portierungslösungen für ältere Systeme unterschiedlichster Art zu erarbeiten. Daher benötige ich Zugriff auf z.B. MySQL. Für eine ältere PervasiveSQL-Datenbank habe ich noch keine Idee, aber egal. Als Interimslösung für kleinere (lokale) Datenbanklösungen ist SQLite3 eben gleichfalls interessant.

Um auf MariaDB (für mich letztlich als Zielsystem) zurückzukommen, welche Komponenten, also welchen Client auf dem jeweiligen Windows- bzw. Linux-System und welche graphischen Komponeten in Lazarus kommen zum Einsatz? MariaDB ist ja ein Fork von MySQL. Es gibt doch keine MariaDB-spezifischen, oder doch?

Benutzeravatar
Winni
Beiträge: 1577
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.2.2, fpc 3.2.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Winni »

Hi!

So etwas wie ./libsqlite3.so" wird niemals unter Linux als Library akkzeptiert. Bibliotheken gehören unter Linux in die entsprechenden Verzeichnisse, wie z.B. /usr/lib oder /usr/lib/locale

Ich hab auch schon erlebt, dass Installations-Scripte vergessen, die Bibliotheken zu veröffentlichen. Nach jeder Änderung muss als root ausgeführt werden:

ldconfig

Einmal zu viel schadet nicht. Dann findet er eben nix Neues.

Winni

Michel
Beiträge: 35
Registriert: Sa 4. Dez 2021, 11:43
OS, Lazarus, FPC: Windows 10 / Ubuntu 20.04 LTS (L 2.0.12 FPC 3.2.0)
CPU-Target: 64Bit

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Michel »

af0815 hat geschrieben:
Do 6. Jan 2022, 17:37
Grundlegend muss die Bibliothek 2x gefunden werden. 1x von Lazarus für die Designzeit und 1x zur Laufzeit vom kompilierten Programm. Der Symlink auf die libsqlite3.so sollte bereits von System richtig angelegt sein. Unter Linux sollte ein herumgemurkse nicht notwendig sein und vor allen kein "./libsqlite3.so".
Allerdings muss ich sagen, das ich seit längeren nichts mit sqlite gemacht habe, sondern mit anderen DB.
Also ich arbeite mit Ubuntu, ein Derivat von Debian. Es gibt nach der Installation von SQL3Lite definitiv nur ein symlink auf libsqlite3.so.0. Irgendwie ist das "libsqlite3.so" drin. Ich kann das umgehen, aber so ist kein zügiges Entwickeln mehr möglich. Es würde helfen, wenn man beides zur Entwicklungs- und Laufzeit solide konfigurieren könnte. Mir würde das ja schon reichen, wenn stets die Laufzeitbibliothek aus dem gleichen Verzeichnis, von wo das Programm aus ausgeführt wird, verwendet wird.
af0815 hat geschrieben:
Do 6. Jan 2022, 17:37
Aber hast du die -dev Pakete von sqlite3 auch installiert ? Sieh auch https://forum.lazarus.freepascal.org/in ... pic=9484.0
Nein. Ich habe lediglich den sqlitebrowser dazu installiert, um die datenbank graphisch bearbeiten zu können.

Aber verstehe ich das richtig, dass diese dazu genutzt werden kann, um eine eigene SQLite3-Bibliothek zu generieren, die bei Kompilierung mit Lazarus dazu gelinkt werden kann und so die Laufzeit-Bibliothek überflüssig macht?

Michel
Beiträge: 35
Registriert: Sa 4. Dez 2021, 11:43
OS, Lazarus, FPC: Windows 10 / Ubuntu 20.04 LTS (L 2.0.12 FPC 3.2.0)
CPU-Target: 64Bit

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Michel »

Winni hat geschrieben:
Do 6. Jan 2022, 18:04
So etwas wie ./libsqlite3.so" wird niemals unter Linux als Library akkzeptiert. Bibliotheken gehören unter Linux in die entsprechenden Verzeichnisse, wie z.B. /usr/lib oder /usr/lib/locale
Nun, der übliche anfangs beschriebene Weg (Client installieren, graphische Komponenten setzen, diese mit einigen plausiblen Daten versehen, der Reihe nach aktivieren) führt eben bereits beim Aktivieren des Connector im Entwurfsmodus zu dem beschriebenen Fehler, mit dem Ergebnis, dass auf diesem Weg eine SQLite3-Datenbank-Anwendung auf einem Ubuntu-System nicht möglich ist. Erst das manuelle Setzen eines Symlinks mit exakt dem Namen "libsqlite3.so" führt hier ein Stück weiter. Aber regulär wird bei Installation der SQLite3-Software nun einmal ein Symlink mit dem Namen libsqlite3.so.0 angelegt.

Ich habe lediglich angefangen, hier mit try and error eine Lösung zu suchen, um herauszufinden, woran es liegt. Dazu kommen noch die regelmäßigen Access Violations während des Entwurfsmodus und Meldungsfenster ohne Inhalt.

Bei Mysql habe ich den Effekt, dass im Entwurfsmodus die Tabelle angezeigt und zur Laufzeit es so aussieht, als ob kein Connect erfolgt wäre. Eine Fehlermeldung erhalte ich auch nicht.

Carsten1975
Beiträge: 23
Registriert: Mi 4. Apr 2018, 18:22

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Carsten1975 »

@Michael Du musst das Package SQLdb installieren in Lazarus. Zusätzlich musst du den MySQL-Connector installieren.
Den findest du hier:
https://dev.mysql.com/downloads/connector/odbc/

Hierbei habe ich mit der Version 3.51.30 und 5.3.7 die besten Erfahrungen, die gar keine Probleme machen, gemacht.

Danach kannst du dann ganz normal die MySQL-Componenten verwenden. Wobei ich für mich ein komplettes dynamisches Package programmiert habe.

Hier ein Auszug von mir:

Code: Alles auswählen


      pvDataSource           : TDataSource;
      pvConnection           : TMySQL56Connection;
      pvQuery                : TSQLQuery;
      pvTransaction          : TSQLTransaction;

      pvDBConnect            := TMySQL56Connection.Create(Nil);
      pvDBTransaction        := TSQLTransaction.Create(Nil);
      pvDBQuery              := TSQLQuery.Create(Nil);
      pvDBDataSource         := TDataSource.Create(Nil);

      // Wenn eine aktive Verbindung besteht, wird sie geschlossen.
      If pvDBConnect.Connected Then
      Begin
        pvDBTransaction.Active := False;
        pvDBConnect.Close;
      End;

        pvDBConnect.HostName            := '127.0.0.1';
        pvDBConnect.Port                :=3306;
        pvDBConnect.UserName            := 'Test';
        pvDBConnect.Password            := 'PW';
        pvDBConnect.DatabaseName        := 'Lazarus';
        pvDBConnect.Open;
        pvDBConnect.Connected           := True;

        pvDBTransaction.DataBase        := pvDBConnect;
        pvDBTransaction.Active          := True;

        pvDBQuery.Transaction           := pvDBTransaction;
        pvDBQuery.DataBase              := pvDBConnect;
        pvDBQuery.PacketRecords         := -1;             // sorgt dafür dass bei .RecordCount alle angezeigt werden, ansosnten 10 oder vorher mit .Last alle einlesen lassen!!
        pvDBQuery.ParseSQL              := True;
        pvDBQuery.ReadOnly              := True;
        pvDBDataSource.DataSet          := pvDBQuery;

      pvDBQuery.SQL.Text     := 'SELECT * FROM testtbl'
      pvDBQuery.Active       := True;
      pvDBQuery.Close;           // Falls vorher bereits eine geöffnet war
      pvDBQuery.Open;
      pvDBQuery.First;


Vielleicht hilft es dir etwas weiter.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6209
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von af0815 »

Michel hat geschrieben:
Do 6. Jan 2022, 18:31
af0815 hat geschrieben:
Do 6. Jan 2022, 17:37
Aber hast du die -dev Pakete von sqlite3 auch installiert ? Sieh auch https://forum.lazarus.freepascal.org/in ... pic=9484.0
Nein. Ich habe lediglich den sqlitebrowser dazu installiert, um die datenbank graphisch bearbeiten zu können.

Aber verstehe ich das richtig, dass diese dazu genutzt werden kann, um eine eigene SQLite3-Bibliothek zu generieren, die bei Kompilierung mit Lazarus dazu gelinkt werden kann und so die Laufzeit-Bibliothek überflüssig macht?
Installiere das sqlite3-dev Paket, dann wird alles gut.

Siehe auch https://packages.ubuntu.com/de/bionic/a ... v/filelist
/usr/include/sqlite3.h
/usr/include/sqlite3ext.h
/usr/lib/x86_64-linux-gnu/libsqlite3.a
/usr/lib/x86_64-linux-gnu/libsqlite3.la
/usr/lib/x86_64-linux-gnu/libsqlite3.so
/usr/lib/x86_64-linux-gnu/pkgconfig/sqlite3.pc
/usr/share/doc/libsqlite3-dev/changelog.Debian.gz
/usr/share/doc/libsqlite3-dev/copyright
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Socke »

af0815 hat geschrieben:
Do 6. Jan 2022, 19:56
Installiere das sqlite3-dev Paket, dann wird alles gut.
Auf dem Entwicklungs-PC passt das dann. Auf einer Installation für Endanwender würde aber immer noch ein anderer Pfad gesucht.
IMHO wäre es durchaus richtig, libsqlite3.so.0 zu referenzieren. Die ".0" indiziert, dass zur ursprünglichen Release-Version noch keine inkompatiblen Änderungen vorgenommen werden. Falls also irgendwann Sqlite3 in einer Version 4.x veröffentlicht wird - ja, das würde den Namen ad absurdum führen - kann man beide als libsqlite3.so.0 (Version 3.x) und libsqlite3.so.1 (Version 4.x) parallel installieren. (Die Erklärung habe ich von https://stackoverflow.com/questions/404 ... n-its-name).
Michel hat geschrieben:
Do 6. Jan 2022, 16:13
Aber ein alternatives SQLite3Connection1.LoadExtension('./libsqlite3.so') geht ins Leere. Witzigerweise wird vorausgesetzt, dass die Connection aktiv ist. Es mag sein, dass ich den Sinn nicht zu erfassen mag.
SQlite ermöglicht es dir, die Datenbankfunktionalität zur Laufzeit zu erweitern. So kannst du in einer Bibliothek eine Prozedur definieren, die dein Programm später per SQL aufruft. Da das immer im Kontext einer bestimmten SQlite3-Datenbankdatei erfolgt, muss du erst die "Verbindung herstellen".
Michel hat geschrieben:
Do 6. Jan 2022, 16:13
Folgt man diesem Krumen, stößt man auf sqlite3conn.pp.
Die Units hängen wie folgt zusammen:
  • SQLite3Conn stellt die Klasse TSQLite3Connection zur Verfügung. Diese ist von TSQLConnection abgeleitet und lässt sich somit recht einfach gegen andere Datenbankverbindungen (ODBC, MySQL/MariaDB, MSSQL) usw. austauschen.
  • sqldb stellt die grundlegende Klasse TSQLConnection bereit. Über die Funktionen GetConnectionDef() und GetConnectionList() kannst sogar abfragen, welche Verbindungstypen in deinem Programm verüfgbar sind. Diese werden automatisch durch die *Conn-Units (wie SQLite3Conn) hier registriert.
  • sqlite3dyn stellt die API für die libsqlite3 bereit. Diese Unit wird durch SQLite3Conn verwendet. Wie der Unitname suggeriert, wird die Bibliothek erst auf Anforderung dynamisch zur Laufzeit geladen; das passiert auch automatisch bei dem ersten "Verbindungsaufbau".
  • Es gibt auch eine Unit sqlite3; wie sqlite3dyn definiert sie die API für libsqlite3. Hier wird die Bibliothek unmittelbar bei Programmstart geladen. Hier hast du keinen Einfluss auf den Dateinamen der Bibliothek. Sie wird nicht duch SQLite3Conn verwendet, sollte aber der Vollständigkeit halber aufgelistet sein.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6209
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von af0815 »

Socke hat geschrieben:
Do 6. Jan 2022, 23:24
af0815 hat geschrieben:
Do 6. Jan 2022, 19:56
Installiere das sqlite3-dev Paket, dann wird alles gut.
Auf dem Entwicklungs-PC passt das dann. Auf einer Installation für Endanwender würde aber immer noch ein anderer Pfad gesucht.
IMHO wäre es durchaus richtig, libsqlite3.so.0 zu referenzieren. Die ".0" indiziert, dass zur ursprünglichen Release-Version noch keine inkompatiblen Änderungen vorgenommen werden. Falls also irgendwann Sqlite3 in einer Version 4.x veröffentlicht wird - ja, das würde den Namen ad absurdum führen - kann man beide als libsqlite3.so.0 (Version 3.x) und libsqlite3.so.1 (Version 4.x) parallel installieren. (Die Erklärung habe ich von https://stackoverflow.com/questions/404 ... n-its-name).
Dann wäre es angebracht einen Feature-Request (oder Bugreport) zu machen. Wie die Paketmanager der Linux Distributionen ihre Pakete zusammenstellen oder benennen ist mir sowieso ein Buch mit sieben Siegel. Und dieses *-dev Paket zu installieren ist laut der Paketliste bei Debian/Ubununtu kein Beinbruch.

Oder man verwendet einen Installer für die DIstribution und setzt mit der Hilfe von dem die richtigen Links. Das ist sowieso die richtigere Vorgangsweise wenn du es für Endanwender ausrollst.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Michel
Beiträge: 35
Registriert: Sa 4. Dez 2021, 11:43
OS, Lazarus, FPC: Windows 10 / Ubuntu 20.04 LTS (L 2.0.12 FPC 3.2.0)
CPU-Target: 64Bit

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Michel »

Zunächst einmal vielen Dank für die vielen Hinweise.

Vorab aber zunächst ein kurzer Bericht zu Lazarus, Windows 10 und SQLite3, vieleicht eher was zu schmunzeln.

Grundsätzlich habe ich den Source-Code meiner ersten Gehversuche in Lazarus in der cloud liegen. Logisch ist, dass die absoluten Pfade hier jeweils differieren. Sofern mit relativen Pfaden gearbeitet wird, sollte das kein Problem sein.

Lazarus in Windows 10 gestartet, eben dieses "Linux"-Projekt geöffnet, F9 und wie erwartet, läuft das auf einen Fehler. Neben den aus Linux stammenden Pfadangaben "./" ist auch eine umbenannte libsqlite3.so in .dll im Programmpfad nicht zielführend. Da werde ich die Hinweise unter https://www.sqlite.org/loadext.html wohl nicht richtig verstanden haben.

Nun denn, von https://www.sqlite.org/download.html flugs die 64Bit-DLL von SQLite3 als ZIP heruntergeladen, im Programmverzeichnis entpackt, nochmal F9.

Ok, erneut Fehler. Es stellt sich heraus, der SQLLoader ist nun nicht nur überflüssig ist, sondern stört. Der Pfad zur Datenbank muss gleichfalls angepasst werden. Dann läuft auch der Zugriff auf die SQLite3-Datenbank gleichermaßen zur Entwurfszeit als auch zur Laufzeit, wie beabsichtigt.

Nun zurück zu Linux, mein Ziel ist ja die plattformübergreifende Entwicklung. Ich werde mich mit den vielen Hinweisen beschäftigen und schauen, ob ich hier letztlich eine Version erhalte, die ähnlich unkompliziert installiert werden kann. Denn irgendwie stört es mich etwas, wenn ich unter Linux eben nicht einfach im Programmverzeichnis die .so einfügen kann, sondern der Anwender erst einmal manuell eine Installation von sqlite3 vornehmen muss, ein weiterer symlink angelegt werden muss bzw. ich mich (schon jetzt) mit dem jeweiligen Paketmanager beschäftigen muss. Eine (autom.) Unterscheidung zwischen 64Bit und 32Bit sollte doch letztlich reichen und sogar ein Herunterladen und Ausführen in einem Verzeichnis als eingeschränkter Benutzer (Windows wie Linux) reichen.

Allerdings sind zur Entwurfszeit bei den Objekte eingetragene Pfade tatsächlich ein Problem, wenn hier bereits während der Entwurfszeit hierauf zugeriffen wird. Auch die Notation für relative Pfade differieren zwischen Linux und Windows. Gibt es hier Abhilfe?

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6209
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von af0815 »

Unter Windows sollte die zum Lazarus passende Sqlite dll sich im Verzeichnis der Lazarus exe befinden und die zur Anwendung passende Dll im Verzeichnis der Anwendung. Wenn man das später auch dem Installer (Bsp. Inno Setup) mitteilt bekommt man Pakete die sehr stabil sind, egal was am Rechner des Users ist. Ausserdem solte man sich gleich angewöhnen die vom System vorgegeben Pfade für die Arbeitsdateien zu verwenden, besonders die Datenbank. Das Programmverzeichnis ist, bei richtiger Installation für den Benutzer ReadOnly. Das vergisst man gerne und hat später die Probleme und das böse erwachen, warum das Programm bei manchen Benutzern nicht läuft.

Ist aber nicht speziell für DB-Applikationen so, sondern allgemeine Rulez
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Antworten