[fpc-pascal]Databases and FPC

[Verity F.M. Brooks]

>
> I now need to rewrite the backend of the system in a manner that will
> protect it from these problems. Which brings me to my question, what do
> you all reccomend ?
> I have seriously considdered mysql, but this has a problem here. Any
> user who discovers the mysql username/password could easilly edit the
> database and up his time considderably without paying. The flatfiles
> were binary, I doubt that many internet cafe users would be able to edit
> it. Even if they could, they are blocked at another point, I can use
> unix permissions. The counter app has SGID permissions and runs as the
> group that owns the database file. The normal users themselves do not
> even have read access to it.
> This option will no longer exist in a mysql backend.
>
> What other suggestions can you make ?
> It is vital that the database be frequently updated on disk because an
> internet cafe could lose a lot of money if a user who simply resets his
> thinclient workstation every few minutes never actually loses time.
>
The quickest and easiest way would be to make a ramdisc, put the relevant
files into it and have the programs use that - have another daemon
synchronise the ramdisk every so often and fit a UPS. If you use a journal
file system you can just sync what has changed which makes it much quicker.
That would be a very quick project.

Another approach, also very easy, is not to bother updating timers all the
time. Just create a secure log of every use logging in and out - unix does
this already in wtmp. Then, on a completely different system, run a batch
job that just reconciles the log file. Then update the users with the final
totals daily from the log file. wtmp is binary, but you can read it with
'last'. I would use awk for that exercise rather than pascal - it is very
good at that sort of job and easy to code.

Even easier, on linux, is to enable system accounting that does all the work
for you, then use those totals to update the user times. System accounting
does have a performance penalty of around 2%, but your program, from the
sound of it, is likely to be impacting performance by more than that so it
would be a performance improvement.