🚀 go-pugleaf

Hans Galema <notused@notused.nl> wrote:
>
>So the client opens the file of the achived data itself?

Correct. Actually, they open an archived data base (single) and
the program access the data files (plural).

> You did not tell how you disallow a client to change the data.

Add, Change, Delete functions check if connected and displays
a warning that they can't do that with archive data (if not
connected). My only objection is that I have similar read
functions in both the server and the client application.

> Better would be to make it impossible to change the data.

That proposition sounds like copy protection ... you can make
it difficult (less so with file access) but not impossible.

> You can do that by setting all the files in the archived
> data to read-only.

The user could always change the file attributes and then modify
the data. If I disallow modifications in code, the user can only
corrupt the data file ... in which case he/she had better have
followed propper backup proceedures.

I believe that a certain amount of responsibility for any
programs' success rests with the administrator. I just don't
have a clear idea of where that line is. For example, checking
that the specified port is clear for use.

Certainly one should be performing error checking but the
administrator should also know what they're doing. The same
is true with providing access to data. It's up to him/her to
protect the data and it's up to you to not enable the user to
have invalid access to the data.

I thought this would be a common issue where users needed to
look at historical data. Because of that, I have a 'SnapShot'
that archives the db at where ever it is at that momment, an
automatic archive when the accounting period is closed and I
have a rollback / forward function that applies changes to any
specified db (archived, SnapShot or live) and rolls it (back
or forth) to a specific date and time.

Is it just me?

~ JD