>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?

Hmm, the accountant would really mostly be using the data with his own copy
of the application, however I am all for having the data in some sort of
format (ie csv?) that can be readily imported into something like Excel (is
that what you meant?). Really the data will only be expported/imported into
and out of the application.

>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.

Alan suggested the same thing, and I do like the idea,

>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.

This is my ultimate goal, ie 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?

>Reading what you say about some
>hundred workers over a season - are we talking about only a few thousand
>records per employer?

yes, though the data may be kept for a few years, (so 1000 employees x 20
timesheets x 5 years = 100,000) but still will be small.

>If so, I would have gone for only one database with
>export/import functions. 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).

yes, exactly what I want.

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

I appreciate all the help.


Thanks,
Cassandra