Datenbankzugriff in Lazarus - eine Odyssee!?

[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.

[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.

[DonAlfredo]

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

100% agreed !

[Socke]

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

[PascalDragon]

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.

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.”

[af0815]

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).

[m.fuchs]

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).

Hmm, das ist jetzt ein bisschen enttäuschend.

[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.

[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]

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.

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.

[six1]

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.

[theo]

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."
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]

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]

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]

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 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 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.