>Notes (and reasoning):

in reality let's think about who is going to use the database - PC users, so
it's unlikely that you will ever strike the hardware exchange problem...
second. it's unlikely that your file size will ever need to span more than
one file - if it does then transporting any file of > 4Gb is going to be
real fun anyway... a zipped backup could be as small as 10Mb on a final db
size of 100Mb which is probably going to be an absolute maximum before you
need to close the books and archive and even then you will need one hell of
a lot of employers, employees, timesheets, payslips etc to get to a file of
that size.

nothing wrong with stubborn :-)

Data Mobility Needs:
any transfer of data (on any system) is going to need a very strict (on the
one hand) but end-user simple (on the other hand) method of backing up,
zipping then unzipping restoring on the receiver side, with all the
inclusive beels and whistles associated with locking out the file
temporarily while it is off-site, then unlockling again up return, as well
as a fool-proof protocol of backup/restore such that you don;t restore an
old copy on the current one or end up with no valid copy to restore.

Implementation thoughts:
if your data is relational, then it will be difficult to transport only
parts of the data in external files, it will need to stick together like
glue. external files are good for information which is standalone or lookup
etc but not a dataset which is full of foreign keys etc. If the imformation
the accoutnant needs fits the bill, then reporting the data from the
external file is fine.

Your client application should have all the savvy to merge employee
records - the database doesn't need that part at all.

Alan