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.