I have been chewing. I think I could chew for another week and still not be
fully sure.

If it is all right, I would like to put forward my intentions (as a result
of the last few days discussion), and would welcome any feedback, any
alternatives etc.


The Program:
An employee management program. Aimed at the employers who employ a good few
hundred itinerant workers over a particular season (ie fruit picking,
cotton-chipping). The program is really aimed at producing reports
(invoices, payslips, pay summaries, Tax Office compliance reporting).
Although (in truth) not essential, the ability for the program to be able to
transfer data (say between the user, and his accountant) would be a major
plus.


Notes (and reasoning):
1).gdb have to be ignored, despite the fact that they are visible in the
Windows Explorer, it is rudimentry to the DBMS that the .gdb files be
treated as if they don't exist.
One reason being that they are hardware dependent.
Another that a database may in fact be spread over several .gdb files,
therefore copying one will in effect give a corrupt (or at least incomplete)
database.
I am sure there are other reasons (actually I would be interested in
them), but these two are suffice to rule this option out.
2) I want to use Firebird, and not Access. (no reasoning, just being
stubborn).

Data Mobility Needs:
1) The accountant needs to be able to receive that client data to use to
create reports (this is more efficient then having the user print them out
himself).
2) The accountant needs to be able to make decisions about employee
legitimacy and these decisions delivered in some way to the client who can
then update the database.A main issue is merging of employees, ie when it is
discovered that one employee has been working under two different names.
3)The accountant/or client may have previously handle the day-to-day
dataentry, however for one reason or another the role might change. The data
needs to be transferable to the other. (ie the accountant handled the role,
but now the client would like to take it over).


Implementation thoughts:
1) This could be handled by the user of an EXTERNAL FILE, which the
accountant could then operate from as a 'read-only' file. For efficiency, it
may be better for the data to be imported into the database (still marked as
read-only), the imported data would need to be removed after the session was
finished.
- I am not sure that it would be good management to import the data into
a database if the intention is to remove it all again. Say the application
'On Close' removed the imported data from the database, what would happen if
the application did not close correctly, thus bypassing the deletion of the
imported data. Could a 'On Trigger' event somehow be used to removed
imported data when the user who imported the data is disconnected?
- Would it be fine to just read & create reports from the EXTERNAL FILE
without importing it into the database?

2)I suppose this is getting into remotely controlling the data, perhaps not
something that should be attempted by a peson new to this game (such as
myself). Really it is nothing that couldn't be achieve by a simple note
saying'John, merge employee AC01 with AD02'. (Of course I can always do it
in a later version!!)

3)This could be handle by doing a serious exporting of the data (into an
EXTERNAL FILE), and actual removal of the exported data from the database.
Then the EXTERNAL FILE could be fully imported (ie full access) into the
database of the new user.

The Database, actually a question:
This is assuming that each application, has one database, and one database
only. I understand how to do this for just one user (ie one employee), but
what about accountants and bookeepers who may use the software for more then
one employer?

My answer:
Kind of dumb, but having an employer table should solve all these problems?
If each employee has one and only one employer, then although an employee
may be duplicated numerous times (this must remain this way due to the
'privacy act'), when working with a particular employer, it can be made to
seem as though it is only his information in the database by use of 'SELECT
... WHERE employer = "fred"' in all the queries.
Doing this (as opposed to having a database for each employer) makes the
application more geared toward any future changes/upgrades. ie the privacy
act is torn-up and the accountant wants a function to access every instance
of a particular employee. (I don't envision a tearing up of the privacy act,
but I think the point is that the program needs to be able to grow!!)


Am I on a better track then I was last night??

Thanks
Cassandra.