Ich nutze SQLite mit FMX auf Mobilen geräten.
Um die Oberfläche responsive zu halten muss ich oft Vorgänge in WorkerThreads auslagern. Ich lagere diese Arbeit in Anonyme threads aus und Zeige in der App einen Sperrbildschirm mit Aktivitäts-Anzeige(Kreisel) oder Fortschritsbalken oder Aktivitäts-Log an.
Sprich es passiert trotzdem alles sequentiel, aber die Oberfläche meldet nicht nach so Dinge wie "Anwendung reagiert nicht mehr, wollen Sie sie beenden?", wenn man auf den Sperrbildschirm tippt oder wischt und 500ms lang nicht drauf reagiert.

Die Programm logik stellt seit kurzem nicht mehr sicher das sequentiel auf die DB zugegriffen wird.
Bevor ich diesen Teil der Logik jetzt Nachliefere habe ich mal folgende Einstellungen ausprobiert.

zusammenfalten · markieren

Delphi-Quellcode:

  FDManager.Active := true;//Hier 6
  FConnection := TFDConnection.Create(self);
  PhysSQLiteDriverLink := TFDPhysSQLiteDriverLink.Create(self);
  GUIxWaitCursor := TFDGUIxWaitCursor.Create(self);
  GUIxAsyncExecuteDialog := TFDGUIxAsyncExecuteDialog.Create(Application.MainForm);

  FConnection.Params.Values['DriverID'] := 'SQLite';
{$IFDEF ANDROID}
  FConnection.Params.Values['Database'] := TPath.Combine(TPath.GetHomePath,
    'APP.s3db');
{$ELSE}
{$IFDEF IOS}
  FConnection.Params.Values['Database'] := TPath.Combine(TPath.GetDocumentsPath,
    'APP.s3db');
{$ELSE}
  FConnection.Params.Values['Database'] := TPath.Combine(TPath.GetHomePath,
    'APP.s3db');
{$ENDIF}
{$ENDIF}
  FConnection.Params.Values['Lockingmode'] := 'Normal'; //Hier 1
  FConnection.Params.Values['Synchronous'] := 'Full'; //Hier 2
  FConnection.Params.Values['SharedCache'] := 'False'; //Hier 3
  FConnection.UpdateOptions.LockWait := true; //Hier 4
  FConnection.UpdateOptions.LockMode := TFDLockMode.lmPessimistic;//Hier 5
  FConnection.Params.Values['DateTimeFormat'] := 'String';
{$IFDEF IOSSIM}
  FConnection.Params.Values['Password'] := '';
  // im Apple SIM geht das nicht mit Password
{$ELSE}
  FConnection.Params.Values['Password'] := 'MyPass';
  // Ohne Passwort fragt er nach einem Passwort! Auch wenn es leer ist.
{$ENDIF}
  PhysSQLiteDriverLink.DriverID := 'SQLite';
  GUIxWaitCursor.Provider := 'FMX';
  GUIxAsyncExecuteDialog.Provider := 'FMX';

Ich habe die Zeilen Hier 1 bis Hier 6 angepasst oder hinzuefügt.
Jetzt bekomme ich keine Fehler mehr wenn ein Query mit locate auf die DB zugreift und sich in einem anderen Thread befindet.

Sorgen diese Einstellungen bereits das Zugriffe aus mehreren Threads sequentiel abgearbeite werden.
Oder muss ich wirklich selber alle SQLITE DB Zugriffe verriegeln? (Leider beherrscht SQLite nur eine einzige gleichzeitige Connection)

Ich nehme an das hier ist der falsche Ort?

Ist doch richtig hier, warum nicht ?
https://www.delphipraxis.net/198724-...t-firedac.html


Ich habe das jetzt nicht festgestelt, mache aber nur wenig Komplexes mit Sqlite.

Auszug von hier:

Zitat:

Many concurrent writers? → choose client/server

If many threads and/or processes need to write the database at the same instant (and they cannot queue up and take turns) then it is best to select a database engine that supports that capability, which always means a client/server database engine.

SQLite only supports one writer at a time per database file. But in most cases, a write transaction only takes milliseconds and so multiple writers can simply take turns. SQLite will handle more write concurrency that many people suspect. Nevertheless, client/server database systems, because they have a long-running server process at hand to coordinate access, can usually handle far more write concurrency than SQLite ever will.

Es könnte sein das Sqlite damit Schwierigkeiten hat, weil es nur für 1:1 Zugriff gedacht ist.

Zitat von Rollo62:

Ist doch richtig hier, warum nicht ?
https://www.delphipraxis.net/198724-...t-firedac.html


Ich habe das jetzt nicht festgestelt, mache aber nur wenig Komplexes mit Sqlite.

Auszug von hier:

Zitat:

Many concurrent writers? → choose client/server

If many threads and/or processes need to write the database at the same instant (and they cannot queue up and take turns) then it is best to select a database engine that supports that capability, which always means a client/server database engine.

SQLite only supports one writer at a time per database file. But in most cases, a write transaction only takes milliseconds and so multiple writers can simply take turns. SQLite will handle more write concurrency that many people suspect. Nevertheless, client/server database systems, because they have a long-running server process at hand to coordinate access, can usually handle far more write concurrency than SQLite ever will.

Es könnte sein das Sqlite damit Schwierigkeiten hat, weil es nur für 1:1 Zugriff gedacht ist.

Ja ich dachte ja auch, dass ich immer nur mit einem Thread drauf zugreife. Aber um ein paar ecken kann es dann wohl doch dazu kommen das 2 threads darauf zugreifen...unter anderem weil Timer in Android mit Threads umgesetzt sind.
Seit ich die Einstellungen von FireDac und SQLite wie oben angegeben geändert habe scheint es so zu sein, dass keine Fehler mehr auftauchen und zumidest lese Zugriffe und locates aus zwei threads verarbeitet werden. Ich denke mal das SQLite das dann selbst Queued.
Ich weiß es nur nicht.
Und ich wünschte es gäbe jemand der das weiß.
Sorry, bin etwas ratlos.