Datenbankzugriff in Lazarus - eine Odyssee!?

[wp_xyz]

Die "Access violation" beim Wechsel von SQLite3Connection1.Connected true auf false im Designmode kommt bei mir unter Windows auch. Das sieht mir eher nach einem Bug aus. Nachdem die DB-Hauptentwickler aus dem FPC-Lager stammen und wenig im Designmode mit Lazarus arbeiten, liegt da noch einiges im Argen. Du müsstest einmal die Bugreports durchsuchen, evtl. ist das schon gemeldet. Andernfalls solltest du einen Bug-Report schreiben.

Lazarus-Bugreports: https://gitlab.com/freepascal.org/lazar ... s/-/issues
FPC-Bugreports: https://gitlab.com/freepascal.org/fpc/source/-/issues

Nach einer Access-Violation der IDE die IDE beenden und neu starten. Am besten nichts speichern, evtl. machst du dir dabei das Projekt kaputt.

Und noch ein Tipp:
Es ist ratsam, ein Projekt nur vorübergehend mit aktiven Datasets und aktiver Connection zu bearbeiten. es ist besser, den Pfad zur Datenbank aus der Connection zu entfernen und erst zur Laufzeit zu setzen, denn wenn der Pfad plötzlich nicht mehr stimmt, kannst du schlimmstenfalls das Projekt nicht mehr laden. So geschehen mit mir, weil es deinen Pfad auf meinem System natürlich nicht gibt. Erst nach manuellem Editieren der lfm-Datei konnte ich das Projekt laden.

Wenn man sich nun denkt, dann speichere ich den Pfad im Designmode relativ ab, kommt das nächste Problem. Denn zur Designzeit ist der Pfad relativ zur IDE, zur Laufzeit relativ zur Anwendung. Die Datenbank-Datei liegt aber relativ zur Anwendung.

[Sieben]

Siehe dazu auch noch mal hier. Seit dieser Änderung habe ich keine Access Violations mehr, und es verhindert gleichzeitig auch die beschriebenen Ladeprobleme.

[Michel]

Siehe dazu auch noch mal hier. Seit dieser Änderung habe ich keine Access Violations mehr, und es verhindert gleichzeitig auch die beschriebenen Ladeprobleme.

Bleibt diese Ableitung gerade bei Nutzung der grafischen Komponenten stets aktiv, d.h. die Eigenschaft Connect lässt sich tatsächlich nur während des Entwurfs auf Aktiv setzen?

Oder müsste ich vollends auf die grafischen Komponenten für den Datenbankzugriff verzichten und alles komplett von Hand entsprechend codieren?

Aber das Problem des Commits, der anstelle des Festschreibens der Änderungen schlicht die Verbindung zur Datenbank kommentarlos kappt, bleibt, oder hat hier jemand mit dem beigefügten Beispiel andere Erfahrungen?

[Michel]

Die "Access violation" beim Wechsel von SQLite3Connection1.Connected true auf false im Designmode kommt bei mir unter Windows auch. Das sieht mir eher nach einem Bug aus. Nachdem die DB-Hauptentwickler aus dem FPC-Lager stammen und wenig im Designmode mit Lazarus arbeiten, liegt da noch einiges im Argen. Du müsstest einmal die Bugreports durchsuchen, evtl. ist das schon gemeldet. Andernfalls solltest du einen Bug-Report schreiben.

Lazarus-Bugreports: https://gitlab.com/freepascal.org/lazar ... s/-/issues
FPC-Bugreports: https://gitlab.com/freepascal.org/fpc/source/-/issues

Ich bin "Gelegenheitsentwickler" und alter Delphi7-Nutzer. Da muss ich mal schauen, ob das sofern das noch nicht reported wurde, ordentlich hinbekomme.

Es ist ratsam, ein Projekt nur vorübergehend mit aktiven Datasets und aktiver Connection zu bearbeiten. es ist besser, den Pfad zur Datenbank aus der Connection zu entfernen und erst zur Laufzeit zu setzen, denn wenn der Pfad plötzlich nicht mehr stimmt, kannst du schlimmstenfalls das Projekt nicht mehr laden. So geschehen mit mir, weil es deinen Pfad auf meinem System natürlich nicht gibt. Erst nach manuellem Editieren der lfm-Datei konnte ich das Projekt laden.

Wenn man sich nun denkt, dann speichere ich den Pfad im Designmode relativ ab, kommt das nächste Problem. Denn zur Designzeit ist der Pfad relativ zur IDE, zur Laufzeit relativ zur Anwendung. Die Datenbank-Datei liegt aber relativ zur Anwendung.

Nun ja, mir ist auch aufgegangen, dass die in Lazarus angebotene Lösung zur plattformübergreifenden Entwicklung für absolute als auch relative Pfade sich wohl auf die nicht-grafische Entwicklung beschränkt. Das dürfte so ziemlich jede grafische Komponenten betreffen, die Eigenschaften bereithält, die zur Entwurfszeit Pfade aufnehmen.

[af0815]

Nun ja, mir ist auch aufgegangen, dass die in Lazarus angebotene Lösung zur plattformübergreifenden Entwicklung für absolute als auch relative Pfade sich wohl auf die nicht-grafische Entwicklung beschränkt. Das dürfte so ziemlich jede grafische Komponenten betreffen, die Eigenschaften bereithält, die zur Entwurfszeit Pfade aufnehmen.

Es ist eine Gewöhnungssache. Bei DB verwende ich in der grafischen Entwicklung sehr wohl auch absolute Pfade - ABER die Komponenten MÜSSEN nach der grafischen Entwicklung deaktiviert werden. Daher zum Start der Applikation ist die DB Komponente inaktiv. Genaugenommen tausche ich die bei mir immer zur Laufzeit gegen eine dynamisch Erzeugte, richtig parametrierte Verbindung aus.
Damit ist für mich das Crosscompiling leichter. Ich arbeite unter Win10/64 und die Programme müssen unter Win/Ubuntu/Debian/Raspian laufen. Daher habe ich mir so ein 'sicheres' System geschaffen. Ausserdem gibt es bei mir nur eine automatisch erzeugte Form und diese erzeugt alles andere, damit weis ich auch genau die Lebenszeit der Objekte und Formulare von der Wiege bis zur Bahre.

[Michel]

Damit ist für mich das Crosscompiling leichter. Ich arbeite unter Win10/64 und die Programme müssen unter Win/Ubuntu/Debian/Raspian laufen. Daher habe ich mir so ein 'sicheres' System geschaffen. Ausserdem gibt es bei mir nur eine automatisch erzeugte Form und diese erzeugt alles andere, damit weis ich auch genau die Lebenszeit der Objekte und Formulare von der Wiege bis zur Bahre.

Nun ja, auch unter Delphi war es für mich normal vor dem Rollout alle DB-Komponenten zunächst grundsätzlich zu deaktivieren, da der ein oder andere Wert eben nicht statischer sondern dynamischer Natur ist. Aber in der Entwicklungs- und Testphase sind es ja genau die voreingestellten statischen "Testwerte", die zunächst einmal aktiviert bleiben, um hier nicht immer wieder über dynamische Effekte zu stolpern. Aber, OK, wenn ich weiß woran es hapert und ich nicht einfach nur zu deppert bin, hilft das auch ein wenig.

[af0815]

Aber, OK, wenn ich weiß woran es hapert und ich nicht einfach nur zu deppert bin, hilft das auch ein wenig.

Lazarus ist nicht Delphi. Lazarus und FPC sind in großen Teilen mit Delphi kompatibel - aber nur in großen Die kleinen Feinheiten können einen am Anfang ziemlich viel Nerven kosten. Delphi ist homogen, Lazarus hat einen zweiten Teil, den FPC. Da ist es manchmal nicht so einfach herauszufinden wer wo was macht.
Ganz schlimm wird es, wennst du nicht von Anfang an ein Projekt Multiplattform machst, können dich die Kleinigkeiten ziemlich ärgern. Und wenn es nur die LineEndings Konstante ist, die dir hilft. Bei Delphi denkt man nicht daran, aber zwischen Win=CRLF, Linux=CR und Mac=LF ist ein kleiner aber feiner Unterschied. Die Kleinigkeit kann dir zum Beispiel Nächte kosten, wenn du das nicht berücksichtigst.

Welcome to reality

[Michel]

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

Wenn ich das richtig lese, wurde das Problem gemeldet und dann einfach nur geschlossen und auf andere Themen verwiesen. Für mich ist es ein bug in der IDE bei Nutzung unter zumindest Ubuntu. Die Komponenten, wie z.B. die Comobo-Box haben zur Laufzeit keine solche Probleme. Schon beim Klick der Combo-Box bei Farben unter Werkzeuge|Einstellungen|Umgebung|Objektinspektor sind nur die Farben und der jeweils mit Mouse-over markierte Eintrag zweifarbig und sichtbar. Damit ist es ganz sicher auch keine Einstellungssache beim Objektinspektor. Aber irgendwie wird das wohl nur noch unter dem Wunsch, ein Theme auswählen zu können, gehandelt.

Ok, das ist jetzt wohl evt. off-topic, ich werde wohl damit leben müssen.

Edit: Unter Ubuntu 20.04 tritt das Phänomen nicht auf. Das passiert, wenn man eine Vielzahl an Systeme zum Test zur Auswahl hat.

[fliegermichl]

Win=CRLF, Linux=CR und Mac=LF ..

Ist umgekehrt, Linux=LF, Mac=CR

[af0815]

Win=CRLF, Linux=CR und Mac=LF ..

Ist umgekehrt, Linux=LF, Mac=CR

Kann sein, ich verwende immer LineEnding. (Oder die sonstigen Helferchen in Lazarus). Ansonsten schau ich an, was in der Statusleiste vom Notepad++ steht.

[Winni]

Hi!

Helferlein für das überstrapazierte Hirn:

Alhabetisch entspricht numerisch:

Linux = #10 = LF
Mac = #13=CR

Winni

[PascalDragon]

Außerdem trifft das mit dem CR nur auf das klassische MacOS (< 10) zu. Seit dem Wechsel auf MacOS X und damit auf ein - an sich - Unix ist es dort ebenfalls LF.

[fliegermichl]

OK, wie wir sehen, ist es am geschicktesten LineEnding zu verwenden

[Michel]

Also, es kommt der Punkt, da muss man erkennen, dass egal wie viel Energie man hier noch investiert, der Erfolg ausbleiben wird.

Das mag an fehlenden Kenntnisse speziell im Umgang mit Lazarus liegen, an zu hohen Erwartungen aus Sicht eines Delphi7-Benutzers bzgl. der grafischen Entwicklung oder schlicht an doch erheblich an einigen mangelhaften Komponenten zumindest für die grafische Entwicklung, was ja Lazarus eigentlich ausmacht.

Ich habe weitere Tests mit SQLite3 gemacht, ich laufe hier immer wieder kurz oder lang auf Access Violations (egal ob Ubuntu 20.04 oder Windows 10), selbst wenn ich die Komponenten grafisch nur ins Form platziere und die Werte und Funktionen manuell mit Leben füllen bzw. ausführe. Und es gibt tonnenweise bekannte bugs die zumindest diese doch recht nichtssagende Fehlermeldung referenzieren. Ich breche das jetzt hier ab. Danke für Eure Mühen an dieser Stelle.

[Sieben]

Vielleicht noch ein letzter Versuch, wenn das größte Ärgernis diese Access Violation ist - und die ist ganz sicher ein Show-Stopper erster Güte. Dazu müsstest du allerdings den hier angesprochenen Vorschlag einmal umsetzen:

Im Package-Menü 'Neue Komponente', in 'Neues Package' wählen, als Ancestor SQLite3Connection auswählen. (Das passende Icon findest du unter /components/sqldb/design der Lazarus-Installation.) Beim Speichern am besten ein frisches Verzeichnis an geeigneter Stelle anlegen. Die IDE erzeugt dir dann ein leeres Gerüst für einen Abkömmling, in den du wie beschrieben unter published die Zeile

Code: Alles auswählen

  property Connected stored False;

einträgst. Im Package-Editor einmal kompilieren und dann unter 'Verwenden' den Punkt 'Installieren' wählen. Die IDE wird sich einmal neu erzeugen, und danach kannst du die geänderte Komponente verwenden. Ein Rechtsklick auf die SQLite3Connection deines Projekts bietet dafür den komfortablen Menüpunkt 'Klasse ändern'.

Bleibt diese Ableitung gerade bei Nutzung der grafischen Komponenten stets aktiv, d.h. die Eigenschaft Connect lässt sich tatsächlich nur während des Entwurfs auf Aktiv setzen?

Nein, es verhindert nur, dass die Eigenschaft Connected in der Formulardatei gespeichert wird, also auch ein automatisches Re-Connect wenn das Projekt geladen oder ausgeführt wird. Du musst die Verbindung dann zur Laufzeit explizit per Connected := True aufbauen, was ja eh ratsam ist. (Und ich vermute da auch noch einen Käfer im Streaming-System, der besagte Access Violation auslöst und auf diese Weise umgangen wird.)