SQLite - Wie Multiuser Zugriff regeln?

[Satty67]

Hallo,

eine Anwendung (Fuhrpark-Verwaltung) speichert Daten in einer SQL-Datenbank. Über eine Zwischenschicht (einfach ein Object, dass die Daten bereitstellt) wird nun die Möglichkeit geboten MSSQL, Firebird oder SQLite zu verwenden.

Grundsätzlich empfehle ich, SQLite nur für Einzelplatz-Rechner zu verwenden, will aber auch hier eine Notlösung für 2-3 Clientrechner bieten.

Es wird meistens lesend auf die Datenbank zugegriffen. Schreibzugriffe bei neuem Fahrzeug, Werkstattbesuche oder Verbrauchswerte eingetragen oder neue Bilder eingefügt werden. Denke also, das es sehr selten zu Schreibkollisionen kommen wird.

Meine Lösung über eine Lock-Table ist für SQLite nicht sicher, da ja kein zentrales DBMS den Zugriff regelt, sondern dezentral die Clientrechner per DLL auf die DB zugreifen. Im worst-case locken zwei Clientrechner die gleiche Tabelle/Datensatz.

***

Meine erste Idee und bisher einziger Ansatz ist, das ich eine Datei zur Datenbank mit anlege. Also neben Daten.sqlite noch eine Daten.lock. Diese Datei Daten.lock wird vom Clientrechner exclusiv (ShareDenyAll) geöffnet, bevor ein Schreibzuriff innerhalb der Daten.sqlite erfolgt.

Welche Lösungen würde Ihr vorschlagen?

[alzaimar]

Zitat:

Zitat von Satty67 (Beitrag 1065425)

Welche Lösungen würde Ihr vorschlagen?

Keine.

Wieso bietest Du überhaupt unterschiedliche DB an? Was Du da machst, hat weder Hand noch Fuss. Du läufst mit so einer Krückenlösung Gefahr, das der Kunde sich die Datenbank zerschießt.

Schmeiss SQLLite doch einfach aus dem Portfolio und verwende nur FB, und von mir aus auch MSSQL (aber wieso eigentlich?).

[Bernhard Geyer]

Zitat:

Zitat von alzaimar (Beitrag 1065438)

... und von mir aus auch MSSQL (aber wieso eigentlich?).

Wenn man nur ein DB anbietet so ist man auch für die nachgelagerten Jobs wie Backups, ... verantwortlich.
Hat man ein DB im Angebot die der Kunde eh schon hat (i.d.R. MS SQL Server, MySQL oder Oracle) so kann man diese Installation verwenden und somit auch vorhandene Backupmechanismen, ...

[Satty67]

Zitat:

Zitat von alzaimar (Beitrag 1065438)

Wieso bietest Du überhaupt unterschiedliche DB an?

Weil es geht... der Zugriff auf SQL-Server Datenbanken ist problemlos und wird über ein jeweils aufs DBMS spezialisiertes Objekt geregelt, es werden auch noch weitere Datenbanken dazu kommen. Innerhalb des Programmes gibt es eine genormte Schnittstelle zum Daten-Objekt, XML usw. wird darüber auch angesprochen werden. (vgl. Linq)

Das ist aber unwichtig...

Die Frage ist nur, wie ich einen sicheren Multiuser-Zugriff mit SQLite lösen könnte.

Gibt es keine sichere Lösung, wird es Singleuser beschränkt, aber auf jeden Fall drin bleiben.

// Es wäre Schade, wenn die Diskussion an der Frage vorbeiläuft, weil ich das aktuelle Einsatzgebiet gleich mit beschrieben habe.

[Florian Hämmerle]

Du könntest eine Liste dazugeben, welche Tabellen gerade in Gebrauch sind. Ist das der Fall bekommt der zweite, der auf die Tabelle zugreifen möchte eine Meldung angezeigt, dass er es in einigen Sekunden noch einmal versuchen soll.

mfg Florian

[himitsu]

Einfache Lösung?
SQLLite nur für SingleUserSysteme.

Sobald es mehr wird, dann ein richtiges DBMS nutzen, welches von sich aus MultiUser anbietet.

[Satty67]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1065451)

Du könntest eine Liste dazugeben, welche Tabellen gerade in Gebrauch sind.

Eine einfache Variante ist meine aktuelle Idee (via gelockter beliegender Datei). Es darf schon unkomfortabel sein, also muss nicht Tabellen einzeln sperren, sondern die ganze Datenbank ist völlig Ok. Denke werde in der Richtung mal weiter testen. (Die *.sqlite Datei selbst kann ich leider nicht "sporadisch" sperren)

Wie himitsu auch geschrieben hat, für richtiges Multiuser muss ein Server-System verwendet werden. Es wäre nur gut, wenn mit SQlite eine Art Basis-Muliuser-Zugriff möglich wäre z.B. für Heimnetzwerke ohne Server.

[Mithrandir]

Zitat:

Zitat von alzaimar (Beitrag 1065438)

Wieso bietest Du überhaupt unterschiedliche DB an?

Wir haben auch einige Kunden, die uns an die Gurgel springen würden, täten wir nicht MSSQL und Oracle unterstützen. Nichtsdestowenigertrotz ist der Einsatz von SQLite für eine Multiuser-Umgebung - Pardon - schwachsinnig.

Ich würde nicht anfangen, mir eine Lösung zusammenzufrickeln, nur weil ich unbedingt bei SQLite MU brauche. Wenns für den Kunden billig sein soll, dann würde ich ihn eher dazu anhalten, MySQL zu installieren, wenn er eine MU-Umgebung benötigt. Das müsstest du natürlich noch unterstützen, ist ja aber nichts unmögliches.

[Satty67]

Ja, es sollen viele DBMS unterstützt werden, gruppiert nach Fähigkeiten.

Wenn es zu riskant ist, dann schiebe ich SQlite in die SingleUser-Gruppe zusammen mit XML, INI usw. (letztere sind sogar nur SingleTable)

[webcss]

Schau Dir mal die Patterns Optimistic-Offline-Locking oder Pessimistic-Offline-Locking an. Die könnten Dir weiterhelfen.