Previously it was stored in Settings.Default - but that is application
specific and separated from the database (so if you delete the database
the timestamps are still there).
So we store the timestamps of the web JSON source in the database itself.
There is an additional timestamp for the database itself - that is
probably not needed and should be removed.
While working on the database code, I realized that QRVFindLastUpdated()
and LocationFindLastUpdated() did not actually return the LastUpdated
timestamp. These functions are used by QRVInsertOrUpdateIfNewer() and
LocationInsertOrUpdateIfNewer(). As the DateTime returned was 1970 (1)
the database was updated even if the timestamp was the same, so no
big deal.
Currently the time stamps of the input files used for updates of the
database are stored in Settings.Default. If the database is cleared
or the stations.db3 file is deleted, the time stamps survive, as they are
stored separately.
That triggers a subtle bug: the location table is updated first and
updates the DB status.
The qrv table than checks the DB status - which is "up-to-date" - and
the timestamp - which may still be set correctly from previous updates.
The qrv table then will never be updated.
Work-around: delete QRV_Update_TimeStamp key in user.config
Hack here: make sure to fill the table if it is empty.
Correct way moving forward: the time stamp needs to go into the database
instead of Settings.Default