David,
I just got back from holiday and have been catching up on the listserver
posts...
In the good old days (pre-Windows, <g>) we used to have a system which updated a
central R:Base database here in the UK with new entries and corrections from
30-40 locations around the world. It worked by sending floppy disks backwards
and forwards so it was a trifle on the slow side (!!) but it was effective. It's
now done in Lotus Notes which is much more efficient but much less fun and does
not give the information in the same way that R:Base did.
However, the way that the system worked was to have a default prefix column and
an autonumber column so that data received from any location was identifiable
and did not duplicate with any other country, eg: UKW0001, FRA0001, SWE0001,
etc. Each location had a one row one column table with their own identifier in
it - this was the only thing that was different about the locations. There was
little duplication of data in any case but this prevented the possibility. We
also had some common items, customer names and addresses, for example, which,
again, were rarely duplicated because the addresses would be different even if
the name was the same. Actually, it was harder to get consistency in the way
people entered company names and so on than it was to prevent duplication.
If you can identify your databases tables into those which are common to all
users and those which are for individual users you can then combine the
individual tables either into a new common table or a view in your master
database. Once you have the new and changed data loaded from individuals you
then export all the new and changed items back to the users. On our system the
data was flagged in such a way that each location was only sent data from other
locations and so didn't have to import and reject their own data.
The only real problem was the time delay (this way pre-Internet) and ensuring
that every location/user regularly sent their updates. In your case, with only
two or three users, you should not have too much difficulty there. If you don't
want to have to set up complicated or massive systems you could always e-mail an
attached file between your user(s) and base in order to distribute exported and
imported data files. Assuming that the amount of data is relatively small then
exporting by users /e-mailing to base/updating the master db/exporting/e-mailing
the users/importing could be quite quick, more or less automatic, and possible
to do on a daily basis.
Hope this helps, if you want any more info then feel free to e-mail me off-list,
Regards, Alastair.
"David Atkinson" <[EMAIL PROTECTED]>@sonetmail.com on 26/08/2001
21:15:14
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: "RBase List" <[EMAIL PROTECTED]>
cc:
Fax to:
Subject: Laptop Updates
With just one reply back so far and I am already delighted I asked the
question. Dennis's mail asks a question which is fundamental to the whole
issue and introduces my preferred choice for a once a day live link up. (PC
Anywhere)
Heated discussions have been about why time should be spent on the day the
BusDev's visits the office, when he has the DB with him all the time. I
have been trying to make the extreme difficulties understood.
Dennis's reply is just what I wanted to hear because
the more I have thought about this the worse it gets and I see no perfect
solutions for a fully automated update from the laptop for the following
reasons.
When we go Multi-User, the Base DB will always be current in terms of the 2
Base users but the laptop will be based on data up to 1 week old.. I see 3
issues
major issues:
1. Any number of new clients could be uploaded. - Not a problem, but it is
possible that because an urgent letter/quotation had to go out, the client
details were passed by phone to Base and the new client being uploaded could
already exist on the Base DB.
This is unimportant ONLY IF both sets of data are exactly the same.
Otherwise it demands a human decision with possibly some manual editing of
the Base data.
2. Amended data for any client will be uploaded from the laptop. However,
on the Base DB, different columns of data for the same client could have
been amended.
In other words, both Base DB data and uploaded data
changes are valid and both must be kept.
3. The amendments could be duplicates and the uploaded data should be
ignored.
I have designed the database so that Clients can only be deleted if they are
unwanted and have no linked data in any of the other tables.
For example, if a Quotation/Tender/Invoice/Payment (and certain other links)
exist, they cannot be deleted. But to overcome large listings of unwanted
data, I have introduced column clStatus (Current, Moved,Closed...) and users
always have a choice over which Status they search on/select allowing data
sets to be limited. (Client) Contacts also have a cnStatus and similar
rules apply.
David Atkinson
skidbusters.co.uk
[EMAIL PROTECTED]
>
