>Gee, I guess you now understand why copying a database file to a different
>architecture will go horribly wrong :)

I do see this, is this common? Is this why even if my requirements are that
the database be singular etc, then exporting/importing is essential.
Exporting to what?
EXTERNAL FILEs? Which are non-relient on the hardware??
The light, I think, is shining...at least on this minor strand of the topic.

Hence it does make sense to have the application have just one database, and
the multiple employers (which I was keen to have seperate), all be apart of
the one database.

The problem I am still having with this is the mobility, importing &
exporting would have to be more time consuming then just being able to
connect to a database (as per my idea of having multiple databases).

>Now this kinda ugly... Usually, you just "export" the data to some format
>that the accountant can use to either create reports from it or to import
>the data into another database (with, for example, stuff from multiple
>employees) and then run his reports on all the data.

This gives me something to think about, however, in my experience (I work
for an accountanting firm), the accountants to a lot of data manipulation,
and correcting/editing of the client data.

Thanks,
Cassandra