At 20:39 25.02.2003 +1000, you wrote:

>Given the same situation,
>1)What would you do to allow the client to transfer data to his accountant
>(for read-only report writing purposes only).

Find out a bit about the accountant. Do they have programs they prefer to
work with? What are the import/export functions of those programs? Then
write export/import functions from/to your program, clearly documenting the
requirements. If it is just set reports the accountant needs, you could
even write a small program which - say - wrote a 'report viewer' and a
firebird database to a CD. Bundle that with your employee management
program, and if it is any good, you may even get a few accountants wanting
you to write programs for them.

>2)Would you use just one database and export/import functions, or would you
>use a database for each employer, such that the database (.gdb file) can be
>copied from Windows Explorer and transfered that way, and such that the
>application reconnects to a chosen database (or can create a new way) via an
>'open'/'new' function in the application?

If I'd been as thorough as Cassandra, I think I would have made sure the
database could handle both small and big customers. But I'm not certain
what this means regarding number of files. Reading what you say about some
hundred workers over a season - are we talking about only a few thousand
records per employer? If so, I would have gone for only one database with
export/import functions (with bigger databases (millions of records), a
more thorough design and care when executing queries are required). But
there is no reason why you cannot export to another Firebird database and
make it possible for your program to work on that copy as well (in case
several employers are within your original database and one employer
suddenly decides he wants a copy of his data to do some work himself).

I do think you have learned a bit since yesterday,
Set