Datenbankzugriff in Lazarus - eine Odyssee!?

Für Fragen von Einsteigern und Programmieranfängern...
DonAlfredo
Beiträge: 64
Registriert: Do 28. Sep 2017, 10:26

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von DonAlfredo »

A bit off-topic perhaps. However.
I would like to advice you to consider the mORMot[2] for database applications. And refrain from visual components, just to enable a bit more abstraction, that will make your sources better to maintain in the long run.
The mORMot[2] is a very advanced ORM. With a steep learning curve. With examples on how to use it. With a very active forum and maintainer. With extensive docs. Using (embedded [and encrypted]) sqlite3 as database engine.
Since my discovery of it, I have never looked back. All past apps have been ported to mORMot. And all new once use mORMot[2] by default.
Just my 2 cents.

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

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von af0815 »

Es stimmt das Mormot eine Blick wert ist, nur sollte man die Standardkomponenten von Lazarus einmal zum laufen gebracht haben, bevor man sich einem derart komplexen (wie gesagt steilen Lernkurve) ORM aussetzt. Aber es ist eine Überlegung wert.

Ich habe mich schon einige Zeit mit tiOPF beschäftigt gehabt, (tiOPF wird IMHO auf den aktuellen Stand bleiben, da es keine Kapazität zur Weiterentwicklung gibt, soweit ich es verstanden habe). Der Unterschied von RAD und ORM basierenden Programmen ist nicht unerheblich, das muss man auch wollen und planen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

DonAlfredo
Beiträge: 64
Registriert: Do 28. Sep 2017, 10:26

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von DonAlfredo »

Der Unterschied von RAD und ORM basierenden Programmen ist nicht unerheblich, das muss man auch wollen und planen
100% agreed !

Socke
Lazarusforum e. V.
Beiträge: 2991
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:
Fr 7. Jan 2022, 08:47
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.
Dann mach das doch jemand!!111einself ... Hatte vorhin nicht die Zeit dazu. Hier ist der Bug: https://gitlab.com/freepascal.org/fpc/s ... sues/39518
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

PascalDragon
Beiträge: 432
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von PascalDragon »

Michel hat geschrieben:
Do 6. Jan 2022, 16:13
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.
Die LoadExtension-Methode ist dazu da weitere Erweiterungen für SQLite zu laden (zum Beispiel Verschlüsselung, Komprimierung, etc.), das hilft dir Null beim Laden der Hauptbibliothek.
Michel hat geschrieben:
Do 6. Jan 2022, 18:31
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.
Das ist aber eben nicht wie die Dinge unter *nix funktionieren. „When in Rome, do as the Romans do.”
FPC Compiler Entwickler

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

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von af0815 »

Socke hat geschrieben:
Fr 7. Jan 2022, 14:28
Dann mach das doch jemand!!111einself ... Hatte vorhin nicht die Zeit dazu. Hier ist der Bug: https://gitlab.com/freepascal.org/fpc/s ... sues/39518
Not a bug - its by design. Das ist kein Bug, das per Design so. Das ist die ultimative Antwort (Kenn ich zur Genüge).
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2434
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von m.fuchs »

af0815 hat geschrieben:
Fr 7. Jan 2022, 22:57
Not a bug - its by design. Das ist kein Bug, das per Design so. Das ist die ultimative Antwort (Kenn ich zur Genüge).
Hmm, das ist jetzt ein bisschen enttäuschend.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

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

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von af0815 »

Für mich ist das nicht enttäuschend, sondern genau das was ich erwartet habe.

Dazu muss man auch sagen, warum hat Debian/Ubuntu etc. den blöden Link in einen -dev Paket versteckt. Das ist kein Problem von fpc/Lazarus sondern der Paketbauer und Philosophie. Und die haben andere Ziele und Vorstellungen als die schräge Community die FPC/Lazarus verwendet.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

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

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Winni »

Hi!

Also nochmals: Debian ist nie als Desktop-OS geplant gewesen, sondern als sicherheitsbewusstes Server-Betriebssystem. Dafür ist es auch gut. Also benutzt es nicht auf dem Desktop, auch seine Stiefkinder nicht.

Und es ist jedesmal dasselbe, wenn ich beruflich einen Debian-Server aufsetzen muß:
Erstmal muss die ellenlange Liste von Paketen abgearbeitet werden, die selbst für den Server-Betrieb fehlen.

Also benutzt es nicht auf dem Desktop.

Es gibt Unmengen von Distributionen, die besser geeignet sind.

Bevor hier wieder flame wars beginnen, nenne ich keine Namen.

Winni

Socke
Lazarusforum e. V.
Beiträge: 2991
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:
Fr 7. Jan 2022, 23:15
Dazu muss man auch sagen, warum hat Debian/Ubuntu etc. den blöden Link in einen -dev Paket versteckt. Das ist kein Problem von fpc/Lazarus sondern der Paketbauer und Philosophie. Und die haben andere Ziele und Vorstellungen als die schräge Community die FPC/Lazarus verwendet.
Das hat nichts mit Debian und Ubuntu zu tun. SUSE und RHEL machen das genau so (hab ich heute nachgeschaut). Die Linux-Distributionen wollen für eine Stabile API-Version einen fixen Dateinamen haben. Für einen Entwickler gibt es dann einen Link auf die neuste Version.
af0815 hat geschrieben:
Fr 7. Jan 2022, 22:57
Not a bug - its by design. Das ist kein Bug, das per Design so. Das ist die ultimative Antwort (Kenn ich zur Genüge).
Ich hab das Ticket wieder aufgemacht. Mir fehlt da ein wenig die Erklärung, warum das bei SQLite so richtig ist, aber MySQL sich lustig die Versionsnummern aussuchen darf. Das hat m.E. nichts mit Design zu tun.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

Benutzeravatar
six1
Beiträge: 558
Registriert: Do 1. Jul 2010, 19:01

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von six1 »

Winni hat geschrieben:
Fr 7. Jan 2022, 23:32
Also nochmals: Debian ist nie als Desktop-OS geplant gewesen, sondern als sicherheitsbewusstes Server-Betriebssystem. Dafür ist es auch gut. Also benutzt es nicht auf dem Desktop, auch seine Stiefkinder nicht.
Wieso denn das?
Ich verwende ausschließlich Debian als System und baue LXCE oder XFCE Desktop drauf.
Sicher, schnell, einfach
Wenn man Windows denkt, dann ist und war Linux schon immer ein K(r)ampf. Da muss man sich einarbeiten und vieles selbst zusammen suchen und erfahren. Bisher habe ich zumindest im Netz alle Hinweise dazu gefunden.
Gruß, Michael

Benutzeravatar
theo
Beiträge: 8817
Registriert: Mo 11. Sep 2006, 19:01

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von theo »

six1 hat geschrieben:
Sa 8. Jan 2022, 09:59
Wenn man Windows denkt, dann ist und war Linux schon immer ein K(r)ampf.
Naja, ich würde sagen: "Wenn man von Windows kommt, dann ist Linux ein K(r)ampf."
Ich würde aber auch sagen: "Wenn man von Linux kommt, dann ist Windows ein K(r)ampf." :mrgreen:
Mir geht es jedenfalls so. Es ist doch hauptsächlich eine Frage der Gewohnheit und womit man sich auskennt.

Und dann gibt es viele, die wollen unbedingt ein "schlankes" Linux (Was immer das sein mag) und ärgern sich dann darüber, dass sie selber Hand anlegen müssen.
OpenSUSE/KDE z.B. ist doch recht stressfrei und komfortabel.

P.S. Wenn es dazu noch Kommentare gibt, sollten wir ein neues Topic aufmachen: z.B. "Betriebssyssteme 2022" in "Sonstiges" > "Dies und Das".

Michel
Beiträge: 22
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 »

Nun, so langsam verzweifle ich hier beim Versuch, unter Linux eine Datenbankanwendung zunächst einmal beschränkt auf SQLite3 zu erstellen. Ich rede hier von einem banalen Programm, dass nur aus den notwendigen DB-Komponenten sowie einem Grid und eine Navigationsbar besteht. Ich habe es nach den anfänglichen Problemen geschafft, die Datenbank und Tabelle zu öffnen und die hierin enthaltenen Daten anzuzeigen, allerdings zunächst einmal nur auf dem jeweiligen Entwicklungs-PC jeweils zur Entwurfs- und Laufzeit und je nach Betriebsysstem mit entsprechenden Änderungen.

Grundsätzlich wird die IDE (Ubuntu wie auch Windows) aber immer instabil, wenn ich die Eigenschaft active der SQLQuery-Komponente auf "false" setze. Hier kommt erst eine Meldung "Access Violation", dann eine inhaltslose Box und ich kann die IDE nur noch ohne speichern der Änderung komplett schließen.

Dann habe ich die Optionen sgAutoApplyUpdates und sgAutoCommit gesetzt, damit Änderungen direkt erfolgen, ohne manuell ein Commit machen zu müssen.

Nun ist die "database is locked". Eine manuelles Commit, also mit einem zeitgleichen false bei diesen Optionen schließt einfach den Zugriff auf die Datenbank ohne jeglichen Fehler.

Ich habe mit

Code: Alles auswählen

sudo apt install libsqlite3-dev
wie vorgeschlagen, auf einem frischen System ausgeführt. Der Zugriff läuft einwandfrei mit dem Tool -

Code: Alles auswählen

sudo apt-get install sqlitebrowser
. Aber in Lazarus nur zum Anschauen. Neue Datensätze oder Änderungen laufen auf den Fehler "database is locked".

Mein Ziel ist es, auf eine Tabelle in einer SQLite3-Datenbank zuzugreifen, Datensätze zu erfassen, ändern und zu löschen. Ich hätte nicht erwartet, hier auf solche massiven Probleme zu stoßen. Ich verfüge aber auch nicht über genügend Kenntnisse, hier in der IDE die Fehlersuche zu betreiben.

Sieben
Beiträge: 144
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: i386

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von Sieben »

Das mit den Access Violations und anschließend unbrauchbarer IDE hatte ich hier auch, es ist sogar vorgekommen, dass beim Versuch, dann doch noch zu speichern, kilobyteweise Müll in die *.lfm geschrieben wurde. Interessanterweise immer beim Property IndexFieldNames der entsprechenden Query. Ich habe mir

1) einen einfachen Abkömmling von TSQLite3Connection geschrieben, der Connected nicht speichert:

Code: Alles auswählen

  TrkSQLite3Connection = class(TSQLite3Connection)
  published
    property Connected stored False;
  end;
2) angewöhnt, aktive TSQLQueries immer nur implizit über die Connection 'auszuschalten'.

Seitdem habe ich diese Art von Abstürzen glücklicherweise nicht mehr gehabt. Trotzdem speichere ich sicherheitshalber vor jedem Ändern des Verbindungszustands.

Was das Problem der Locks betrifft - ist im SQLiteBrowser evt eine Änderung noch nicht geschrieben? Macht es überhaupt einen Unterschied ob er nebenbei ebenfalls läuft oder nicht?

Und zu dem von dir ursprünglich auch angesprochenen Problem der 'unsichtbaren Einträge' im Objekt Inspektor hilft dir vielleicht dieser Thread weiter.

hum4n0id3
Beiträge: 114
Registriert: So 5. Mai 2019, 15:23

Re: Datenbankzugriff in Lazarus - eine Odyssee!?

Beitrag von hum4n0id3 »

Winni hat geschrieben:
Fr 7. Jan 2022, 23:32
Also nochmals: Debian ist nie als Desktop-OS geplant gewesen, sondern als sicherheitsbewusstes Server-Betriebssystem. Dafür ist es auch gut. Also benutzt es nicht auf dem Desktop, auch seine Stiefkinder nicht.
Das wäre mir neu, das Debian nur als Server-Betriebssystem gedacht worden ist. Auch lässt sich Debian schlecht verallgemeinern, den Debian selbst besteht ja aus Stable, Testing, Sid und Experimental. Allein in Sid kann sich schon Software tummeln, da ist selbst Arch zu alt :D Ich hatte kurzzeitig Sid in den Fingern gehabt, da wurde PHP8 in der Alpha Version angeboten, als PHP8 in der Alpha Version zur verfügung stand :D Moderner gehts kaum noch.

Linux! wurde am Anfang gar nicht als Server-System gedacht und nur als Betriebssystem für Home-Computer :)

Als Linux-Distro nutze ich Fedora. Erst nachdem ich sqlite-devel installiert habe, konnte ich auch auf die SQLite-Datenbank zugreifen. Ist nicht anders als bei Debian auch.

Antworten