SQLite und konkurrierender Zugriff mit FireDAC

[scrat1979]

Eventuell wäre hier Absolute Database in der MultiUser Edition eine Option. Allerdings kostenpflichtig. Ob es sich für ein Spassprojekt lohnt kannst nur du entscheiden. Ich arbeite sehr gerne damit

[jobo]

Was ich an dem Szenario interessant finde:
Du sagst, es gibt keine hohe Last, wenig Teilnehmer/ Konkurrenz. Trotzdem tritt aber der Fehler auf.

Tritt er auf, weil Du Lasttest machst und ihn den Fehler provozierst oder tritt er bereits in der beschriebenen Normalsituation auf?

Und wie sind die Parameter konkret?
Nutzeranzahl:
Schreibzugriffe pro Minute, Stunde, Tag:

[EgonHugeist]

@Cody,

der Fehler tritt auf, weil FireDac ein Performace-Blender ist. FireDac setzt alle !DB defaults! zu max Performace-settings. Wogegen alle ander Komponenten das nicht machen. Bei Zeos mußt du das explizit setzen.

Schau mal in die Antwort von:
https://stackoverflow.com/questions/...qlite-database
Dort steht beschieben, wie du FD wieder für konkurierende Zugriffe nutzbar machen kannst.

kleines ABER:
SQLite ist rasend schnell mit den FD settings. Zum Vergeich: https://synopse.info/forum/viewtopic.php?id=4472
Jedoch in den default-settings solltest du mit wirklich erhöhter Disk-Aktivität rechnen.
SQLite ist einfach nicht dafür gemacht, aber kann es.

[jobo]

Interessant!
normal versus exclusive Lock würde ich jetz nicht gleich als Performance Blendung bezeichnen.
Ein Exclusive Lock entspricht ja vollkommen der Bestimmung von sqlite und neben der dadurch gewonnenen Performance, bringt es ja im Zweifel auch "bessere" Daten (wobei ich nichts über die Qualität des "Normal Lock" Modes von sqlite weiß)

[Codehunter]

Also den Fehler habe ich gezielt provoziert indem ich auf einem Rechner mit einem 1-Sekunden-Timer immer von einer Tabelle gelesen habe und auf einem anderen Rechner mit einem INSERT einen Datensatz in diese Tabelle eingefügt habe. In der Praxis wäre das Intervall eher bei 60 Sekunden, aber nur weil die Wahrscheinlichkeit des Fehlers dadurch kleiner wird, wäre das ja noch keine gute Lösung.

Der besagte Fehler trat auf dem lesenden Rechner auf. Ich habe diesen Fehler ja, nach allem was in den von Günther verlinkten Artikeln zu lesen ist, erwartet und deswegen provoziert. Interessant fand ich die von mir verlinkte Seite mit dem WAL-Modus von SQLite, den ich in diesem Szenario ausprobieren wollte.

Die Hinweise mit den Performance-Einstellungen werde ich mir anschauen sobald ich wieder dazu komme. Sowas hatte ich auch im Verdacht. Ich hätte überhaupt kein Problem damit, wenn die lesende Seite so lange warten müsste, bis die schreibende Seite fertig ist und ihren Exklusiv-Lock wieder fallen lässt.