Datenbankzugriff in Lazarus - eine Odyssee!?

[Michel]

Also, die Access Violations treten auch beim Ändern von Werten in Komponenten wie TCSDataset auf. Und da stehen die SQLdb-Komponenten völlig außen vor.

Ich erhalte das Problem zudem Access Violation auch wenn ich während der Laufzeit den Connector auf true setze. Ich verstehe ja Deinen Lösungsansatz als Absicherungs, damit ein versehentlich vergessenes auf false setzen beim Connector während der Entwurfszeit nicht später Problem verursacht.

Aber ich kann ja bei diesen Komponenten noch nicht einmal den Wert während der Laufzeit auf true setzen.

Nein, ich fürchte, die grafische Entwicklungsoberfläche ist noch nicht reif für den praktischen Einsatz. Für mich war das mit Blick auf Delphi interessant. Wenn ich dann doch wieder alles von Hand coden muss, dann verliert diese IDE ihren Vorteil.

[wp_xyz]

Nein, ich fürchte, die grafische Entwicklungsoberfläche ist noch nicht reif für den praktischen Einsatz. Für mich war das mit Blick auf Delphi interessant. Wenn ich dann doch wieder alles von Hand coden muss, dann verliert diese IDE ihren Vorteil.

Ich kann das absolut nicht unterschreiben. Das visuelle Layout der Komponenten funktioniert einwandfrei auch ohne aktive Datenbank-Verbindung. Ob jetzt das Grid leer ist oder nicht, ist doch egal.

---

Was ist TCSDataset?

Um auszuschließen, dass die komplexe SQLDb-Architektur etwas mit dem Connected-Problem zu tun hat, habe ich mit einem TBufDataset zur Designzeit die FieldDef für ein einfaches Feld eingegeben und die Tabelle mit "Create Dataset" im Kontextmenü erzeugt. Dabei springt BufDataset.Active im Objekt-Inspector auf true (aber erst nachdem ich in den Objekt-Inspector oder auf das Komponenten-Icon auf dem Formular geklickt habe - das ist wahrscheinlich ein anderer Bug...). Nun kann ich aber problemlos Active zwischen false und true hinundherschalten.

Dann habe ich die IDE neu gestartet, wieder ein TBufDataset mit einem Feld erzeugt (wie eben). Wenn ich jetzt im aktiven Zustand des Dataset eine Datasource auf das Formular klicke, mit dem Dataset verbinde und Dataset.Active auf false umschalte bekomme ich die Zugriffsverletzung. Und zwar jedes mal wenn ich Active umschalte.

Bei einer erneuten Wiederholung lasse ich Dataset.Active auf false, bevor ich mit Datasource verbinde - nun kann ich wieder problemlos Active zwischen true und false hinundherschalten.

Leider kann man das zur Laufzeit nicht nachstellen. Der code wäre:

Code: Alles auswählen

procedure TForm1.FormActivate(Sender: TObject);
begin
  BufDataset1.FieldDefs.Add('test', ftInteger);
  BufDataset1.CreateDataset;
  BufDataset1.Active := true;
  Datasource1.Dataset := BufDataset1;
end;

Ich denke, ich werde mir die Zeit nehmen müssen, das in einem Bugreport zusammenzufassen, so dass sich das die DB-Entwickler ansehen können.

[af0815]

Hat irgendjemand, schon mal das Logging von Lazarus eingeschaltet und Lazarus von der Kommandozeile gestartet ?! Normalerweise gibt es Hinweise was da faul sein könnte und ohne die Infos und Beispiel kann man sowieso keinen Bugreport schreiben.

[Michel]

Hallo zusammen,

ich habe eine Nacht drüber geschlafen, dann die frisch angekündigte stable version von Lazarus (2.2.0) nebst aktuellem free pascal installiert bzw. das bestehende System aktualisiert und offensichtlich sind hierin eine Vielzahl an massiven Problemen mit der IDE nun behoben.

Für Ubuntu 18.04/20.04 siehe https://sourceforge.net/projects/lazaru ... s%202.2.0/

Installation (Upgrade):

Code: Alles auswählen

sudo apt install ./fpc-laz_3.2.2-210709_amd64.deb  ./fpc-src_3.2.2-210709_amd64.deb  ./lazarus-project_2.2.0-0_amd64.deb

Dies betrifft die vielen AccessViolations (@wp_xyz: ich meinte TCSVDataset) die bei so manchen DB-Komponenten aus dem Reiter "DataAccess" bzw. "SQLdb" aufgetreten sind. Auch die Abstürze der IDE (Streaming, usw.), sofern ich während des Entwurfs Änderungen an den Eigenschaften vornehme, treten nun nicht mehr auf. So erscheint nun ggsf. (korrekterweise) eine Meldung, wenn ich versuche, eine Eigenschaft der TSQLQuery-Ableitung zu ändern, während diese "active" ist, usw. Ansonsten lassen sich die Eigenschaften Connected bzw. active der DB-Komponenten problemlos ändern.

Allerdings bleibt es dabei, ich kann eine SQLite3-Datenbank bzw. Tabelle zwar hierin öffnen, Änderungen / Ergänzungen vornehmen, allerdings nicht in der Datenbank festschreiben. Ein Commit schließt sang- und klanglos schlicht den Zugriff auf die Datenbank ohne ein Commit, ein vorgeschaltetes ApplyUpdates schlägt fehl, mit der Meldung "locked database", was aber nicht der Fall ist. Und natürlich greifen alternativ gesetzte "sqoAutoComm" und "sqoAutoApplayUpdates" gleichfalls ins Leere. Ich mache hier ersteinmal einen Haken dran. Ich bin noch nicht soweit, hier einen soliden bug report zu machen, zumal ich als Einsteiger z.Zt. nicht ausschließen kann, die Komponenten falsch mit Daten gefüttert zu haben. Das Beispiel habe ich ja schon unter viewtopic.php?p=125928#p125928 geladen.

[Sieben]

...ein vorgeschaltetes ApplyUpdates schlägt fehl, mit der Meldung "locked database", was aber nicht der Fall ist.

Doch - da du die Verbindung schon zur Entwurfszeit auf Connected gesetzt hast, hat die IDE den Daumen drauf. Wenn du die mal schließt und dein Projekt 'solo' laufen lässt, funktioniert es (ApplyUpdates vorausgesetzt). Besser aber, die Verbindung erst zur Laufzeit aufzubauen und vor Probeläufen im Designer zu schließen. Und dass ein Commit die angeschlossenen DataSets schließt, ist dokumentiertes Verhalten. Entweder CommitRetaining nehmen, bei der Query sqoKeepOpenOnCommit setzen, oder sie nach dem Commit wieder öffnen. Welche Vorgehensweise sich da wirklich empfiehlt oder nach welchen Kriterien sich das richten sollte, weiß ich allerdings auch (noch) nicht. Vielleicht kann jemand anders dazu noch was sagen...

[Michel]

Also, zunächst erstens ist die Access Violation wieder da. Ich werde mal schauen, ob das an persistenten Daten im Benutzerprofil von Lazarus liegt.

Zweitens database locked weil im Entwurfsmodus bereits geöffnet, deutet auf einen exklusiven Öffnungsmodus im Entwurfsmodus hin, was zunächst einmal keinen Sinn macht. Ist aber irgendwie schon seltsam, weil der die Datenbank im Entwurfsmodus zeitgleich mit DB Browser keine Probleme hat. Nun, denn.

Egal, wie vorgeschlagen, alles vor dem F9 deaktivieren und beim Start im Form.Create aktivieren

Code: Alles auswählen

procedure TForm1.FormCreate(Sender: TObject);
begin
  SQLite3Connection1.Connected:=True;
  SQLTransaction1.Active:=True;
  SQLQuery1.Active:=True;
end;

Ein nach den Änderungen via Knopf ausgelöstes:

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
begin
  SQLQuery1.ApplyUpdates();
  SQLTransaction1.Commit;
end;

schreibt die Änderungen fort und trennt kommentarlos die Verbindung zur Datenbank.

Also nochmal:

Action von Transaction auf Commit setzen, Nur noch

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
begin
  SQLQuery1.ApplyUpdates();
end;

Erfolg und Datenbank bleibt aktiv.

Und nochmal:

sqoAutoApplyUpdates auf true, kein explizites SQLQuery1.ApplyUpdates(); und wieder Erfolg.

Natürlich folgt kein refresh, werde ich wohl bei AfterPost integrieren.

Also, erst einmal Danke für die Hinweise. Aber es ist schon klar, dass das so ganz sicher nicht dokumentiert ist, oder? Also für Einsteiger ist das schon eine ziemliche Hürde. Dazu kommen noch die Access Violations, deren Ursache ich noch nicht gefunden habe. Mühsam nährt sich das Eichhörnchen. Von einer halbswegs vernünftigen Anwendung bin ich noch sehr weit weg.

[hum4n0id3]

Versuche es mal mit Lazarus 2.0.10. Ich glaube das ich dort den Access Violation Fehler nicht gesehen habe. Jedenfalls als ich mit SQLite das besagte Programm geschrieben habe, hatte ich derlei Probleme nicht. Mein hochgeladenes Beispiel zeigt auch den Access Violation Fehler, funktioniert aber und ich kann Daten schreiben.

[Sieben]

Zweitens database locked weil im Entwurfsmodus bereits geöffnet, deutet auf einen exklusiven Öffnungsmodus im Entwurfsmodus hin, was zunächst einmal keinen Sinn macht.

Das kommt vermutlich daher, dass bei SQLdb alle SQL-Statements ein implizites StartTransaction ausführen, anders als das Standardverhalten, das ich noch von D7 und ADO meine in Erinnerung zu haben, wo ich eine Transaktion immer nur dann gestartet habe, wenn ich auch wirklich schreiben wollte (es gibt die Option stoExplicitStart bei TSQLTransaction, damit habe ich aber auch noch nicht gespielt). Das heißt, sobald du im Entwurfsmodus eine aktive Query hast, hast du auch eine 'offene' Transaktion und damit zumindest bei SQLite auch einen Lock. Du hast ja in deinem Testprojekt auch nur ein Commit, ohne explizit eine Transaktion gestartet zu haben.

Die Access Violations hatte ich auch bei 2.0.10, das scheint mir also keine Option zu sein.

[hum4n0id3]

Die Access Violations hatte ich auch bei 2.0.10, das scheint mir also keine Option zu sein.

Dann wäre es zumindest ausgeschlossen das der Fehler erst mit 2.0.12 passiert.

[Michel]

Also, die Access Violations treten vor allem zur Entwurfszeit und bei verschiedenen Datenbank-Komponenten auf. Man dann die in der aktuellen Version (2.2.0) von Lazarus zunächst ignorieren, die IDE bleibt in dieser Version zumindest stabil, d.h es treten keine Streaming-Folgefehler auf, die die IDE instabil machen.
Ich denke, das Problem liegt im Entwurfseditor und irgendwie an dem im jeweiligen "Benutzerprofil" persistent erstellten Daten.