SQLite - Wie Multiuser Zugriff regeln?

[Satty67]

Zitat von Assarbad:

Daß es möglich ist, hat niemand bezweifelt. Aber irgendwie geht mir hier unter, daß SQLite dafür einfach nicht das richtige Werkzeug ist.

Hier werden zwei Dinge vermischt und dadurch eine für mich nicht nachvollziehbare Bewertung der aufgetauchten Projekt-Details abgegeben.

SQLite muss nicht Multi-User fähig werden, es wurde nur die Frage gestellt ob es möglich wäre und wenn ja wie. SQLite passt natürlich auch als SingeUser Datenbank ins Konzept. Wer meine Idee genau angeschaut hätte, hätte vielleicht auch gesehen, das bei meinem "MultiUser"-Ansatz auch immer nur ein exlusiver Schreibzugriff erfolgt wäre.

Das hat aber nichts mit der Gesamt-Idee zu tun, die jeder hier schon in spezialisierter Form bereits nutzt und von mir nur unspezifischer umgesetzt werden soll. Hier wird genauso banal kritisiert, obwohl es genau betrachtet nur einen Schritt neben bestehenden und bereits intensiv genutzten Systeme stehen soll.

Wer DB Zugriffskomponenten wie ZEOS etc. nutzt, kann sich ja mal anschauen, wie er in einer einfachen Anwendung auf MSSQL, Firebird oder SQLite zugreift und welche Befehle er nutzt. Kann sich Fragen was der Sinn hinter SQL/SQL-92 war... und sich am Ende vielleicht wie ich fragen, warum hier zwingend so strickt unterschieden werden muss.

***

Ich hab' keine Lust mehr das weiter zu verteidigen (man wird ja sowieso als bekloppt abgestempelt).
Ihr findet es Mist und gut ist, wenn es in meinen Projekten gut arbeitet reicht mir das.

[Assarbad]

Zitat von Satty67:

Wer DB Zugriffskomponenten wie ZEOS etc. nutzt, kann sich ja mal anschauen, wie er in einer einfachen Anwendung auf MSSQL, Firebird oder SQLite zugreift und welche Befehle er nutzt. Kann sich Fragen was der Sinn hinter SQL/SQL-92 war... und sich am Ende vielleicht wie ich fragen, warum hier zwingend so strickt unterschieden werden muss.

Standardisierung, würde ich meinen. Kenne nur wenige die darauf wert legen nur diese Untermenge zu benutzen. Als ich mit SQLite angefangen hatte, wurde ich augenrollend von einigen Kollegen mit schiefen Blicken bedacht.

Zitat von Satty67:

Ich hab' keine Lust mehr das weiter zu verteidigen (man wird ja sowieso als bekloppt abgestempelt).

Gerade das hatte ich versucht zu vermeiden. Tut mir leid, wenn es so rüberkam.

[Satty67]

Zitat von Assarbad:

Tut mir leid, wenn es so rüberkam.

Du warst nicht gemeint, sorry wenn Du durch das Zitat am Anfang meines letzten Posts für Dich den Eindruck hatte.

***

Das Ausgangsproblem (Fragestellung in Post #1) habe ich gelöst, wie es alle lösen:

Multi-User-Zugriff <> Parallel-Zugriff

In einem Multi-User System können mehrere User eine Datei bearbeiten (nicht gleichzeitig, aber nacheinander). Liegt ein Bild/Dokument etc. auf einem Netzlaufwerk, dann kann ich es auf Client-PC #1 bearbeiten und danach auf Client-PC #2.

Bearbeitungsprogramme setzen beim Öffnen das Bild auf ShareDenyWrite. Dadurch kann man sich während Client-PC #1 bearbeitet auf Client-PC #2 ein SnapShot holen, aber nicht parallel bearbeiten.

Mit dem verwendeten Wrapper für SQlite3.dll hatte ich keine interne Lösung entdecken können. Deshalb löse ich das zumindest innerhalb meiner Anwendung mit einer parallel beiliegenden Datei. Somit stelle ich sicher, wenn auf die Datenbank von unterschiedlichen Usern/Client-PC zugegriffen wird, kein kollidierender Schreibzugriff herrscht.

***

Das andere im Thread hochgekommene Thema (Uni-Zugriff auf mehrere DBMS) soll entsprechend den Forenregeln hier nicht weiter Thema sein.