On 29/06/2012 9:25 PM, Simon Slavin wrote:
Your app or the shell tool is running while you delete the file, or do you
quit, delete, then restart them ?
When you specify the database file to open are you specifying a full path, from
the 'C:\' on down, or are you relying on some default folder being specified by
something ? The usual trick is that your application is opening a database
from one folder, the shell tool is opening the database from another folder,
and the one you're deleting is one or none of them. Make sure everything
specifies the full path, just until you've figured out this problem.
It's all fully-qualified paths, no default folders :) And yes, the db is
deleted when everything is closed (and checked using Task Manager).
It's probably best to start off by assuming that the SQLite shell tool does
exactly what it's documented to do 100% of the time. There are thousands of
users of it out there and a bug like you describe would have been reported to
this list many times by now.
You should be able to use a database file as a messaging system. Put a row in
it using the shell tool, then read it out using your app and make sure it has
the right value. Then put a row in it using your app and read it out using the
shell tool. If that's not working, they're opening different files, your app
is buggy, or you have a hardware failure of some sort.
What's weird here (I'll just re-instate it) is that when a DB is created
from within the app, it seems to inherit some entries from an already
deleted DB. I'm not sure how that's possible, but it appears to be what
I'm seeing (if the .dump command in sqlite shell is reporting the truth,
which I do assume it does).
I'll try to reproduce this using the shell tool (creating the DB) and
see what happens.
Dennis
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
