SQLite und DBA - UPDATE / INSERT führt bei Multiuser zu Absturz

[Ahk_fan]

Hallo,

ich habe eine Frage zu SQLite und DBA von IsNULL https://autohotkey.com/board/topic/7117 ... mysql-ado/. Leider habe ich nach langen stöbern auch im Forum nichts passendes gefunden.
Ich habe ein Programm erstellt zur Verwaltung von Dokumenten mit einer ToDo-Liste, die ich angezeigt bekomme mit einer Liste aller noch zu erledigenden Dokumente, die nach dem Lesen auf erledigt gesetzt werden sollen. Bis jetzt habe ich das Programm alleine benutzt, jetzt soll ich es auf MultiUser erweitern, damit die ganze Abteilung das auch machen kann und jeder User seine offenen Aufgaben sieht. Jeder User startet das Programm bei sich auf dem Rechner aber von einem Netzlauftwerk, d.h. keine eigene Installation, die sqlite3.dll liegt auch zentral, also nichts lokales.

Jetzt versuche ich verzweifelt nach einen "UPDATE ..."/"INSERT..."-Befehl die DB wieder freizugeben. Wenn ein User schreibend zugreift, wird für alle anderen gesperrt, soweit klar(und alle Schreibvorgänge des 1. Users sind auch erfolgreich!), aber warum wird nach dem Schreibvorgang nicht wieder freigegeben? Wenn danach oder parallel ein anderer User schreibt, stürz das Script der anderen User ab. Lesen über SELECT geht dagegenen bei allen einwandfrei. Die Datenbank-Datei bleibt gesprerrt bis der 1.Schreibende User das Programm beendet, dann kann der nächste wieder schreiben...

hier mein Teil meines Codes:

Code: Select all

currentDB.BeginTransaction()
{
RunSQL("UPDATE '51_Work' SET DatumErledigt = '" A_Now "', Status = 3 WHERE Vorgang = " RowText "")
}currentDB.EndTransaction()

das

Code: Select all

currentDB.BeginTransaction()/currentDB.EndTransaction()

habe ich auch erst nachträglich dazugemacht, aber es bringt nichts und meldet auch keinen Fehler. Über Errorlevel und SQLite_LastError() bekomme ich auch nix raus. SQLite_CloseDB(currentDB) funktioniert auch nicht,

und die Funktion:

Code: Select all

RunSQL(SQL){
	if(IsObject(currentDB))
	{
		state := ""
		if(Trim(SQL) == "")
		{
		   ;SB_SetText("No SQL entered")
		   Return
		}
		
		try {
			rs := currentDB.OpenRecordSet(SQL)
			if(IsObject(rs))
				return rs
		} catch e {
			MsgBox,16, Error, % "OpenRecordSet Failed.`n`n" ExceptionDetail(e) ;state := "!# " e.What " " e.Message
		}
		if(state != "")
			SetStatusBar("RunSQL")
	}else {
		MsgBox,16, Error, No Connection avaiable. Please connect to a db first!
	}
}

Ich kenn zwar die Einschränkungen von SQLite etwas (vor allem durch lesen von zig Foren inzwischen), aber evtl hat jemand einen Tip oder Vorschlag. Danke schon mal.

Gruß

[just me]

Moin,

es ist bekannt, dass SQLite Schwächen mit Multiuserumgebungen und Netzwerkzugriffen hat. Allerdings sollte ein einziger schreibender Zugriff eines Nutzers nicht die komplette Datenbank/Tabelle dauerhaft sperren.

Deine RunSQL() Funktion irritiert mich aber. Darin wird für jedes SQL-Statement bedingungslos currentDB.OpenRecordSet(SQL) aufgerufen. Das macht aber für

Code: Select all

RunSQL("UPDATE '51_Work' SET DatumErledigt = '" A_Now "', Status = 3 WHERE Vorgang = " RowText "")

keinen Sinn, weil INSERT oder UPDATE Statements kein brauchbares Recordset liefern. Möglicherweise entsteht aber ein SQLite QUERY Objekt, das anscheinend nicht wieder entsorgt wird und vielleicht eine Sperre hinterlässt.

Du kannst mal versuchen, ersatzweise currentDB.Query(SQL) aufzurufen. Notfalls wären auch noch die Dateisystemrechte der Benutzer für die DB-Datei zu überprüfen. Falls Du die von IsNull bereitgestellte sqlite3.dll benutzt, könnte auch ein Update auf eine neuere Version helfen.

[Ahk_fan]

Hallo,
danke erstmal für die Tipps!
Ich habe es von mehreren Rechnern versucht gleichzeitig zu nutzen, alle Lesefunktionen gehen, aber Write geht immer nur von dem ersten der es schafft zu schreiben, danach bleibt die DB gesperrt, bis dieser User das Programm beendet.

- die sqlite3.dllist ganz frisch von der Webseite von sqlite

Ich habe die Funktion RunSQL(...)durch currentDB.Query(...) ersetzt. Funktionieren tut es genauso wie bisher, und auch gleiche Fehler

Habe noch einen Versuch mit folgender Konfiguration gemacht(um die Netzlaufwerkgeschichte mal auszuschließen):
Rechner 1: auf einem freigegebenen Verzeichnis das Programm+DB abgelegt
Rechner 2: Zugriff auf das Verzeichnis Programm am Rechner 1 als User 1--> Programm starten --> geht
Rechner 3: Zugriff auf das Verzeichnis Programm am Rechner 1 als User 2 --> Programm starten --> geht
Rechner 2: Zugriff auf das Verzeichnis Programm am Rechner 1 als User 1--> UPDATE... aufgerufen --> geht
Rechner 3: Zugriff auf das Verzeichnis Programm am Rechner 1 als User 2--> UPDATE... aufgerufen --> Programm stützt nicht ab, aktualsiert aber auch nicht
Rechner 3: Zugriff auf das Verzeichnis Programm am Rechner 1 als User 2--> UPDATE... aufgerufen --> Programm stützt ab

laut: https://www.sqlite.org/lockingv3.html wird

On Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls

genutzt um die DB zu schließen, aber warum wird der LockFile() nicht zurückgenommen????
Der LockFile()-Befehl wird vom Windows-System gesetzt, aber nicht zurückgesetzt.
Wenn ich mit dem SQLiteDatabaseBroser die DB öffne kommt die Meldung

Datenbankdatei konnte nicht geöffnet werden. Grund: database is locked

. Erst wenn ich mein Programm schließe geht es wieder.

Ich suche mal weiter, freue mich aber über Vorschläge

Gruß

[just me]

... genutzt um die DB zu schließen, aber warum wird der LockFile() nicht zurückgenommen????
Der LockFile()-Befehl wird vom Windows-System gesetzt, aber nicht zurückgesetzt.

Das glaube ich nicht. Die LockFile() Funktion wird mit Sicherheit von SQLite aufgerufen und muss dann auch von dort wieder zurückgesetzt werden.

Das von IsNull verwendete Skript SQLite_L.ahk basiert auf einem älteren Skript von mir. Außerdem hat IsNull versucht, die Datenbankzugriffe für alle unterstützten DB-Systeme zu vereinheitlichen. Das mag unerwünschte Nebeneffekte haben. Ich habe aber keine Lust, das genauer zu untersuchen. Hast Du mal mein neueres Skript Class_SQLiteDB.ahk probiert?

[Ahk_fan]

Hi,
kann ich verstehen, dass du keine Lust hast, habe ich nämlich auch nicht mehr! Ich bin schon dran es auf dein Script umzustellen
Wird ein lustiges Wochenende

Trotzdem Danke für die Zeit
Gruß