Question about SQLite database's valid_upto field

[Thomas Baumgart]

On Dienstag, 2. Juni 2020 11:51:19 CEST Prasun Kumar wrote:

> Hi everyone,
> I asked for help on this in my previous mail but it may have been lost due
> to the long threads with the same subject I was creating. So sending it
> again. I will avoid that in future.
> 
> When at compile-time the database is created locally, how to decide which
> dates to put in the valid_upto field?

Which data will be used in this step and where does it come from? Is it part
of the source code? Please excuse in case I am asking dumb questions, but I
am not 100% sure about the whole process (initially and during operation).

I understand, that at some location, a file will be provided to the users.
How does this file get created? Who creates it (role, not application)?
IMHO this file should contain all necessary information (incl. any validity
periods). And then if distributed with the source code contains all
necessary data. Again, IMHO it does not make sense to take the Bundesbank
file as is and distribute it. It needs to be verified and amended with
additional information such as the valid_upto field.

> The current sort code file only contains the information of which entries
> were removed this quarter but the file does not contain any
> date information. So, how to ensure consistency among all the users'
> databases?

The consistency among all users can only be given after all users loaded
the same specific file.

> For example:
> If the script infers the date from the current date (by assuming the first
> day of the current quarter as the date till the deletions were valid),
> then, if the user compiles the code after missing any quarter, the data of
> valid_upto field will be inconsistent with other users.

Hope that helps.

Thomas

-- 

Regards

Thomas Baumgart

https://www.signal.org/       Signal, the better WhatsApp
-------------------------------------------------------------
A clearly defined problem is half the solution! -- Julian Huxley
-------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-finance-apps/attachments/20200602/b3af8963/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-finance-apps/attachments/20200602/b3af8963/attachment.sig>