I have to admit that giving users that unhindered ability to backup and
restore data files would scare that crap (excuse me) out of me. They all
have an incredible knack for not following procedure even clicking the right
button. I do much prefer to keep my gdb files out of everyones reach and be
in sole control of how, when they are backed up and especially how, when
they are restored.. remember to restore a copy of a database it must then
get the previous file name so overwriting a good gdb file with a "wrong" one
is very very easy.

I would - I think - just create a set of reports which can be generated at
month end and handed over to the accountant with a report reader if magnetic
or just on paper for the accountant to review.

One gdb for all employer's and there employees and sufficient security such
that no two sets can be confused, accessed... perhaps separate tables for
each employer would be a better way so that internal permissions could be
managed more easily. You could e.g. make different logins for different
employers and a setup routine to create the correct metadata each time a new
employer is signed up. that would prvide far greater file stability

Alan


-----Original Message-----
From: Cassandra Harley [mailto:cass.harley@...]
Sent: Tuesday, 25 February 2003 9:40 PM
To: ib-support@yahoogroups.com
Subject: RE: [ib-support] Opinions Sought (Non-technical)

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

Just when I was convinced that I had to ignore the .gdb files..

>second. it's unlikely that your file size will ever need to span more than
>one file

Good point (again, I was trying to convince myself, plus stick with my
'forward thinking' motto)

>nothing wrong with stubborn :-)

good good!

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

All the scary stuff aside, an assuming I can do it (...or at least figure
out how to do it correctly). Is this a valid option??

>then it will be difficult to transport only parts of the data in external

files
I guess I had intended on transfering it all.

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

Of course, what I am referring to is the accountant being able to view the
data at the office and decided 'these merges need doing', and then the best
way to transfer this decision to a reality on the client computer (ie, just
a paper note, or can it be done programmatically..), gosh I could get
complex and have some sort of file that is output by the 'accountant
computer' to be imported to the 'client computer' that would present (in a
very user friendly, HCI considered way of course) the client with options to
accept or reject the accountants decisions...

Questions:
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).
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?



Thanks again
Cassandra







To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/