SQLite-Fehler: "database is locked"
Mehrere Möglichkeiten:
> Wenn Du mit dem SQLite Database Browser die SQLite DB bearbeitet und
diese DB-Manipulation nocht nicht gespeichert hast, dann ist die DB noch
gesperrt. Oder mit einem anderen DB-Tool ...
> Wenn Du nicht sauber Deine DB-Connections öffnest und schliesst. Da SQLite eben keine DB Server ist, muss man da sehr sauber programmieren. D.h. mann muss immer genaus wissen, wie der DB Zugriff der App erfolgt .
Tabellar
> Wenn Du mit dem SQLite Database Browser die SQLite DB bearbeitet und
diese DB-Manipulation nocht nicht gespeichert hast, dann ist die DB noch
gesperrt. Oder mit einem anderen DB-Tool ...
> Wenn Du nicht sauber Deine DB-Connections öffnest und schliesst. Da SQLite eben keine DB Server ist, muss man da sehr sauber programmieren. D.h. mann muss immer genaus wissen, wie der DB Zugriff der App erfolgt .
Tabellar
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Also das erste kann ich Ausschliessen... Beim zweiten kann es aber duchaus vorkommen... Ich weiß nur nicht, wie ich das ändern kann
Das ganze kann passieren, wenn der Client einen Download startet (der mal locker 15-30Min dauern kann)
Wenn nun der Client abbricht, wird auch IMHO das CGI-Skript einfach abgebrochen, ohne das ich die Chance hab, ein db.close() zu machen... Ich glaube das macht Apache einfach so
Hm... Vielleicht kann ich allerdings mit [urlhttp://wiki.python.de/Neue_Tricks?#Atexit]atexit[/url] machen...
Naja, vielleicht sollte ich dann doch besser MySQL nehmen...
Das ganze kann passieren, wenn der Client einen Download startet (der mal locker 15-30Min dauern kann)
Wenn nun der Client abbricht, wird auch IMHO das CGI-Skript einfach abgebrochen, ohne das ich die Chance hab, ein db.close() zu machen... Ich glaube das macht Apache einfach so
Hm... Vielleicht kann ich allerdings mit [urlhttp://wiki.python.de/Neue_Tricks?#Atexit]atexit[/url] machen...
Naja, vielleicht sollte ich dann doch besser MySQL nehmen...
Auf die Schelle vielleicht folgende Idee:
SQLite DBs sind ja im Prinzip Dateien. Also könntest Du ja für jeden
Download eine neue, temporäre SQLite DB erstellen (geht ja schnell ).
Ein DB Handler könnte dann dann zyklisch prüfen (>zentrale Download Tabelle, mit dem Download DB Name...), ob der Download erfolgreich war (Flag in der Download-DB). Wenn ja, merged er die Datei (?) in die zentrale
FileDB...
Tabellar
SQLite DBs sind ja im Prinzip Dateien. Also könntest Du ja für jeden
Download eine neue, temporäre SQLite DB erstellen (geht ja schnell ).
Ein DB Handler könnte dann dann zyklisch prüfen (>zentrale Download Tabelle, mit dem Download DB Name...), ob der Download erfolgreich war (Flag in der Download-DB). Wenn ja, merged er die Datei (?) in die zentrale
FileDB...
Tabellar
Uups, da hab ich wohl upload mit download verwechselt... Für dentabellar hat geschrieben:...Ein DB Handler könnte dann dann zyklisch prüfen (>zentrale Download Tabelle, mit dem Download DB Name...), ob der Download erfolgreich war (Flag in der Download-DB). Wenn ja, merged er die Datei (?) in die zentrale FileDB...
Download könnte ja das BLOB als Temporäre Datei abgelegt und somit
unabhängig vom DB Zugriff downgeloaded werden...
Warum nicht PostgreSQL ? Als Pythonianer ist PostgreSQL doch ideal,jens hat geschrieben:Naja, vielleicht sollte ich dann doch besser MySQL nehmen...
da Python auch als prozedurale, serverseitige Sprache verwendet werden
kann (PL/Python) .
Tabellar
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ich glaube ich verwechsel auch im meinem Falle Upload/Download... Also mein PyDown-Skript sickt eine Datei zum Client, also macht dieser einen Download...
Ne, wenn, dann MySQL, weil es im Windows-XAMPP Paket eh enthalten ist... Es soll problemlos damit laufen können...
Ne, wenn, dann MySQL, weil es im Windows-XAMPP Paket eh enthalten ist... Es soll problemlos damit laufen können...