>I would - I think - just create a set of reports which can be generated at
>month end and handed over to the accountant with a report reader if

magnetic

>or just on paper for the accountant to review.

This has me thinking.
I had kind of envisioned a 'read-only' environment where an accountant could
create reports based on a exporting of the client data.
the idea of, not having the client export data to give to the accountant,
but instead create a report file (of some shape or form) to be used with a
view of some sort (could make them .pdf reports, or could embed a report
viewer in the application, or could create a stand-alone viewer), is
something to give some thought to.

>One gdb for all employer's and there employees and sufficient security such
>that no two sets can be confused, accessed... perhaps separate tables for
>each employer would be a better way so that internal permissions could be
>managed more easily. You could e.g. make different logins for different
>employers and a setup routine to create the correct metadata each time a

new

>employer is signed up. that would prvide far greater file stability.

At this stage am not concerned about permissions, I am happy for a user to
have complete access.
This sort of thing is over my head at the moment, however if it is the
better way to do things then I will put the time in to learn about it more.
More then likely in place of an 'open' function, I would allow the user to
'select' the employer, and then all functions in the application would
relate to that employer.