so all references at this point to the database and database file are gone (they were NILed away).
but when I try to delete the file, I get an errorcode 104 which is file in use.
they way I am trying to delete the file is by deleting the temporary directory it is in with all its contents. And this method has deleted every other file in the temp directory excluding the gDB file.
now if I pass along the temp directory folderitem to the main window, and have the main window delete it after the document window is closed, it works like a champ. its like the close/databasefile=NIL/=NIL process isnt closing the file handle out.
any suggestions on how to track down the file lock/handle?
am I smoking crack?
do I need more sleep?
Do you perhaps have an active recordset or something else that is holding a reference to the database, so that it can’t be let go of?
and the document window closing releases THAT object?
First off it sounds like you should be using an in-memory database if you are just creating it and deleting it for one window, but you may want to try “New” or a Timer for your code after the window is closed.
If you close an sqlite database, then there’s no code left running that could keep it busy.
It is, however, possible that some other process takes a look at it, such as Spotlight. Try disabling Spotlight for that volume and see if that makes a difference. If so, you will have two options: Use a Timer to periodically try to delete it, i.e. wait for spotlight to finish its thing, or prevent Spotlight from looking at it in the first place. I believe there are special extensions or file attributes you can use for that, not sure, though.
not necessarily true… it some other control (binding) is holding a reference to the database, then the close attempt would have failed, and the issue indicated in the OP would occur
the dbase file i part of a larger document so in-memory doesnt work in this case. Otherwise I would agree with you.
Emile, I dont since I dont know how to do that? how do you clear the cache?
[quote=261341:@Thomas Tempelmann]If you close an sqlite database, then there’s no code left running that could keep it busy.
It is, however, possible that some other process takes a look at it, such as Spotlight. Try disabling Spotlight for that volume and see if that makes a difference. If so, you will have two options: Use a Timer to periodically try to delete it, i.e. wait for spotlight to finish its thing, or prevent Spotlight from looking at it in the first place. I believe there are special extensions or file attributes you can use for that, not sure, though.[/quote]
It isnt Spotlight as the issue is happening on Windows, not Mac. And I can delete the file via Explorer whenever I want to without issue.
I agree Dave. I just dont find where there is any references to the DB. It is a hunt…
[quote=261347:@Norman Palardy]An unclosed recordset would do that
They hold a reference to the DB they came from[/quote]
As far as I know every recordset is closed. Again that is part of the hunt I mention above.
If you have used any BEGIN TRANSACTION statements be sure to either Commit or RollBack them. An open transaction may make the database think there is a reference.
Have the same problem (Xojo 2018 R4, Win 10 64bit).
I copy original “SQLite A” to “SubFolder\SQLite B” (doing some SQL in B) then to share as “SQLite C”.
Delete of “SubFolder\SQLite B” does work then!
Without using a sub folder, “SQLite B” could not be deleted.
At a guess, I would think that the system is protecting the Share. Since the original of the share, “SQLite B” is linked to C, C would become an orphan if B is deleted. Try unsharing B before deleting it (or the sub folder.)
