David,
I do a lot of work in an application that is used in an environment
such as you're discussing. There is a central DB and 1000+
"points of entry". Some of those work live via an internet
connection and others do data uploads/downloads to the "base"
db. I support the folks working with data "batch" transfers. They
find the live site to be slow and a bit arcane (thank you R:Base
<g>), and usually want to integrate other office functions.
If you are able to follow Dennis' advice without giving up needed
functionality, do so; because otherwise you do have some serious
work ahead. You will have an easier time because you're working
from the same platform, and there doesn't seem to be much issue
as to "who can change what", but it's still significant.
Maybe a pcAnywhere session every evening where he makes
revisions and additions and at the end downloads the entire db???
Failing that, here are some of the early points of what you might
consider:
1) New records must be flagged as such
2) Every table must be date/time stamped for comparison. As well,
each update must be date/time/USER logged.
3) Plan on a routine of exporting/loading a file for each table with
modifications. At this point the actual db never gets copied, _each_
system is updated. I use temp tables for import and modify each
cell in the target table. This is only necessary if you want to
check/control modifications to that level, as is the case with my
clients (ie they would never replace a row that contained an SSN or
Licensing info).
4) For the app I work with, there has yet to be an occurrence where
two people modified the same record between updates with
different data (knock on wood <g>) I think the reason has to do
with design:
a) The tables are not very wide, in general, so there is less
chance of there being an overlap in modifications.
b) There are heavy restrictions on who can change what, so
there is a natural tendency for the "right" data to be entered (if you
enter an address and I enter an address on the same day, they
really should be the same).
You will probably want a routine to compare mods as mentioned
above, and it's probably easier than you might think. Could be
handled at update time.
5) In my situation the base DB keeps a copy of each row of data
prior to _any_ modifications. When an update is requested the
whole shebang is sent (very unnecessary). From that, any record
can be reconstructed from day one.
And on ...
Good hunting David (keep the adrenalin flowing <g>)
Be Petersen
On 26 Aug 2001, at 21:15, David Atkinson wrote:
> 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]
> >
>
>
