David:
One of the things that is missing from the current release of R:Base is a
native way to handle replication of databases and replication conflicts.
Most of the heavy-weight databases have ways of dealing with these issues.
I have a client who has a number of sites and I couldn't provide them with
a way to share their databases until I was able to interconnect the sites
with VPNs and, at some sites where VPN connectivity was not available,
frame relay. I also set up Terminal Server to access the single database at
a central site from all of the other sites.
Initially, I had them use pcAnyWhere, but MS W2K Terminal Server
outperforms pcAnyWhere. Terminal Server is a much more cost effective
solution because it only requires one system (a server) at the central site
instead of a system for each user that pcAnyWhere requires.
I don't know how many existing R:Base users need multi-site database
support, but I'm sure that if enough users let RBTI know that they need it,
RBTI will include this sort of feature in future releases. (From my
experience with many software publishers, I've found the folks at RBTI to
be one of the best, if not the best, when it comes to supporting their
users!)
As I stated earlier, I've come up with a viable solution for my client by
giving them access to their database from one central site, but I think I'd
also like to see support for database replication in future versions of
R:Base.
(Replication support allows multiple "replicas" of a database. When a
replication is initiated, the replica databases are compared to determine
what info has been added, deleted, or modified since the last replication
and then transfers only the changes. There are all sorts of varieties of
replication - push, push/pull, pull/pull, etc. And in a true replication
environment, there is no such thing as an original and a copy because all
instances of the database are replicas.)
Lotus Notes/Domino and Microsoft SQLServer are two systems that support
replication.)
Also to keep your s/w costs down, buy R:Base Runtime instead of full-blown
R:Base. You should have only one set of database developers who have access
to the R: prompt. All of your users should only have Runtime applications
that control their access to the database.
Tony
Anthony Schmidt
President
The Computery Ltd.
One East Main Street
Bay Shore, NY 11706
Voice 631-665-8100
Fax 631-969-5988
"William Cook"
<[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>
Sent by: cc:
owner-rbase-l@son Subject: Re: Finding Files
etmail.com
08/26/2001 01:44
PM
Please respond to
rbase-l
----- Original Message -----
From: "David Atkinson" <[EMAIL PROTECTED]>
To: "RBase List" <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 9:27 AM
Subject: Finding Files
> You folks give your time so freely. A very big Thank You to one and all
for
> your great and varied solutions.
>
> Tom - VB (Gulp!)
> I'm an Engineer making my living by Engineering not a programmer. We're
> only a small company but we make a big impact in terms of road safety in
the
> UK and I somehow got involved in this because no-one else would.
>
> Ever since System V, Sheila and my daughter Sue have fought a losing
battle
> for my not-at-work, but-still-working-at-home time. It's been an unpaid
> labour of love(??) and it is now just expected that Dave will fix it.
> So VB - I just have to say a big NO! However, now's a good chance to
say
> Tom, I have found the often large chunks of code you have put up in the
past
> of great help. Bonza and keep it up Mate.
>
> To date we have been single user (mainly because of my naked fear of
going
> multi-user!!) and things have kept going pretty well, but we have
> deliberately upgraded to 2000 6.5++ to go multi-user.
>
> We currently run a three machine network under win98, but having taken on
a
> Business Development Manager, It has been decided he will be given a
Laptop
> and will have a full version of the DB on his stand alone laptop.
>
> We consider he will come to the office once a week and upload his
database,
> leaving later that day with an upgraded and packed new version. I've
> developed a long and meaningful relationship with 'the men's room' just
> thinking about the implications and have made two important discoveries
> which may be of help to anyone in a similar situation in the future -
> Adrenalin has a smell and it's coloured.
>
> Having posed relatively few questions in the past, perhaps 'long service'
> entitles me to these.
>
> 1. Autonumbering (say cliID) in the above situation.
> Currently a simple autonumber increments by 1 for each new client.
> False inserts are ignored - having gaps in the numbering sequence is not
an
> issue.
If the non-networked machine (laptop) must also create new cliID values,
you
might consider having those be even numbers stepping by two and the
networked machines share the odd numbers stepping by two. To allow for
future expansion you might have everyone step by ten and have your two (and
later three, etc) cliID values end in different numbers. Networked machine
cliID vlaues end in 0, laptop 1 end in 1, laptop 2 end in 2 etc.
> 2. How do I tackle the following situation.
> Monday we all start with the same database.
> The Bus Dev Mgr gets his version on his laptop
> Tues/Wed/Thur/Fri he meets several Clients and makes some changes to
their
> data on his machine.
> During that same week, we at Base also make changes to some of those same
> clients on our Base database.
> The following Monday BusDevMgr comes in to upload his laptop and later
that
> day leaves with a fully updated and packed version.
I think this is not easy. What comes to mind is to create triggers on the
files where both networked and non-networked might make changes. The
trigger
would insert the before/after information in the log file. Merging the log
files will handle all of the easy changes. But, what do you do if more than
one machine changes exactly the same column in a row. If both values can be
correct, I suspect a human will have to resolve those on a case by case
basis.
> PC Anywhere with evening downloads is something I have considered, but
that
> will not overcome the issues the above situation will create. I have
> devoured Anne Gillihans Inside R:Base and am now thinking euthanasia is
the
> next best move!
I have done this. We had several trucks with onboard inventory traveling in
their own areas. They would make sales and each evening use pcAnywhere to
send their invoices to home base. The nightmare was to handle telephone
dropouts safely; neither to miss anything nor duplicate anything.
> I know from past experience those of you who feel able will give your
best
> advice and will commit a fair bit of thought and time to your answers.
> Again I can only say Thanks in advance, but as this is such an important
> area, I'm sure there are many 'silent learners' like me who will also
> benefit greatly from your learned solutions.
>
> David Atkinson
> skidbusters.co.uk
>
> [EMAIL PROTECTED]
>
Bill Cook aka [EMAIL PROTECTED]
Kent WA USA
