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

[mw71]

Hi

I am using File.LastModified to check if the (SQLite) file has changed since the last backup.
I changed the file today (add an entry, 9/22/19), but the result is 9/19/19. I check with Totalcomander, the DB file is the change 19.9., the SHM and WAL file is 22.9.19. (correct timestamp).

Why have the db File the old/wrong Timestamp??, what can i do to get the correct timestamp)

 

[emexes]

assume that the database is made of all three files

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.

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

 

[mw71]

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.

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

 

[Erel]

Journal Mode = off,

See @emexes answer above.

 

[emexes]

I have to find a way to safely close the database

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

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

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.

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

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.