Database is locked, sqlite

[kpmais]

Hallo, Experten.
Dieser Error treibt mich in den Wahnsinn.
Prinzipiell tritt der immer mal auf und ich bekomme ihn gefixt. In der Regel ein Aufmerksamkeitsfehler bei dem irgendwo eine Base nicht geschlossen wurde. Kein Problem.
Diesmal tritt er nur auf, wenn ich die App mit Debugger starte.
Debuggere ich bis zu der Routine, in der ausgelöst wird, und lasse ich dann durchlaufen - kein Fehler.
Halte ich vor der Routine an und lasse dann durchlaufen - Fehler.
Starte ich ganz ohne Debugger - kein Fehler.
Das verflixte daran ist ja, dass eben dann KEIN Fehler ausgelöst wird, wenn ich mir die Routine anschaue.
Das ist fast wie in der Quantenmechanik.
Schaue ich hin - ändert sich's und ich erkenne nichts mehr.

Ich bräuchte einen Tipp, WIE ich da weiter nachschauen könnte.
Code posten macht keinen Sinn, das ist einfach zuviel.

[kpmais]

Also, doch noch zur näheren Erläuterung und mit etwas Code.
Der Fehler wird wohl durch folgende Routine ausgelöst, bei der auf Shellebene (Linux) auf die Datenbank zugegriffen wird.

Code: Alles auswählen

procedure TFrmOverview.getSqlSystemTab(dbName, Command: string; TabName: string
  );
var SysString : string; SysList : TStringList;sqlShellProcess : TProcess; CommandString,myhome : string;
begin
  myhome := '/home/kpm/';
  syslist := TStringlist.Create;
  sqlShellProcess := TProcess.Create(nil);
  if FileExists(myhome + 'systabtemp.csv') then
    deletefile(myhome + 'systabtemp.csv');
  if FileExists(myhome + 'sqlshell.txt') then
    deletefile(myhome + 'sqlshell.txt');
  syslist.Add('.mode csv');
  syslist.Add('.headers on');
  syslist.Add('.output ' + myhome + 'systabtemp.csv' );
  syslist.Add('select * from ' + command + '("' + tabname + '");');
  syslist.Add('drop table if exists systabtemp;');
  syslist.Add('.import ' + myhome + 'systabtemp.csv' + ' systabtemp');
  syslist.Add('.quit');
  syslist.Add('.exit');
  syslist.SaveToFile(myhome + 'sqlshell.txt');
  commandstring := 'sqlite3 ' + dbname + '  ".read ' + myhome + 'sqlshell.txt' + '"';
  sqlshellprocess.CommandLine:= commandstring;
  sqlshellprocess.Execute;
  freeandnil(sqlshellprocess);
end; 

Was hier geschieht ist folgendes:
Es wird eine Textdatei erzeugt, die dann auf Shellebene mit dem Befehl:
sqlite3 <Datenbank> .read <textdatei>
abgearbeitet wird.
Das funktioniert auch und macht, was es machen soll.
Aber nach dem Zugriff auf Shellebene scheint die Database nicht geschlossen zu werden.
Das ist im Moment mein Gedanke.
Aber durch .quit und .exit sollte das doch so sein.
Ich bin ratlos.

[six1]

ich hatte verschiedentlich Probleme, die ich mit einem application.processmessages lösen konnte.
Da waren manchmal Dinge nicht zu Ende bearbeitet und Anderes bereits gestartet...
Hört sich wirr an, ist es auch und überdies sehr schwer zu lokalisieren!

Good luck

[kpmais]

He, Michi ..., danke schön, war eine gute Idee

Hatte allerdings noch nicht ganz gereicht.
Ein Sleep(200) muss noch dabei ...., 100 war noch zu wenig.
Aber so läuft es ..., suuuuper ...

Klaus-Peter ....

[six1]

Vielleicht solltest du da eher mit Rückgabe arbeiten auf der Shell!; also abwarten an der Stelle des Shell-Aufrufes, bis der komplett ausgeführt wurde.
Wenn dein SQL Server mal etwas länger braucht, stehst du vor dem selben Schlamassel

[kpmais]

Ging mir eben auch durch den Kopf, was ist "wenn's mal wieder etwas länger dauert ....'?
Die Sache mit der Rückgabe ist mir aber nicht eingefallen . Auch gute Idee.
Ich schaue mir allerdings mal noch die Sache mit 'commandline' an, die ja deprecated ist. Evtl. hat es sogar damit zu tun.
Von der Alternativen habe ich jedoch (noch) keine Ahnung.
Jedenfalls habe ich da die Option [poWaitOnExit] entdeckt.
Evtl. bewirkt die etwas.
Mal ausprobieren.

[six1]

Schau dir mal TProcess an...
https://wiki.freepascal.org/Executing_E ... rograms/de

[kpmais]

Habe das mit Commandline trotz depri gelassen und
sqlshellprocess.Options:= sqlshellprocess.Options + [poWaitOnExit];
ergänzt.
Und es funzt !!!!!!!!!
Yipiiiieeeeee ..........

[kpmais]

... was soll man(n) da noch sagen?
... wer lesen kann ist klar im Vorteil ...