Android Question File.LastModified, trouble with (wrong) timestamp

Erel said:

assume that the database is made of all three files

Click to expand...

If this means: use the latest (greatest, largest) timestamp of the three files as the last-modified time of the three files collectively, then... that might* work.

or change the journal mode. You don't need it to be in wal mode.

Click to expand...

Journal mode = DELETE is the alternative mode: WAL journals the changes, then updates the database if all is good; DELETE (= ROLLBACK) updates the database and journals the previous state, and rolls it back (undoes the updates) if something goes wrong.


* because if Sleep(100) somewhat fixes the problem, this suggests that there is a lag in the file timestamp being updated

Erel said:

I think that you are doing a mistake. Either assume that the database is made of all three files or change the journal mode. You don't need it to be in wal mode.

Click to expand...

o.k., but change to Journal Mode = off, i think it's not the best if i read the Documentation

At the moment I think the best is the Sleep (100) solution.

I think the problem with working / not working is the following:
Adding a record is easy (Open, INSERT IN..., Close, Sleep)
The "show file" is more complex in my app. I have to find a way to safely close the database

mw71 said:

Journal Mode = off,

Click to expand...

See @emexes answer above.

mw71 said:

I have to find a way to safely close the database

Click to expand...

I thought we'd found a way to do that:

mw71 said:

Now i have, after open, write and and close, add a SQL.Initialize and direct after a SQL.Close.

Click to expand...

where the SQL.Initialize seems to want to begin with a clean slate, and so flushes any pending changes from the writeahead file to the main database file, updating the main database file's timestamp in the process. Job done.

mw71 said:

That's Workaround works, but it's not nice.

Click to expand...

Agreed, it'd be nicer if the SQL.Close did it instead, where you and I and most everybody else would expect it to be done, but... sometimes, job done is as good as we're gonna get. Perhaps there is a reason for doing it this way, like... perhaps they discovered that most database Closes are done during shutdowns triggered by battery being low or flat, and corruptions were occurring because there was often not enough time or energy to complete the file updates.