Hi

I am muddling through converting an application from Delphi7/DBISAM3 to
DelphiXE/ElevateDB2 and just got everything going.  I have also changed the
method of generating unique keys so that I am prepared for replication.
This is just on a small internal system but it is a trial for what we need
to do to our major application.

I have read the salesman replication example and I have a vague
understanding of how it works, but have a couple of questions that I need to
answer before I go off on the wrong track.

1.  Is replication achievable without the use of an EDBServer running?

Most of my current DBISAM3 sites are running peer-to-peer or are single user
and it would be nice for the boss to be able to replicate to his notebook
and take the system home (or out in the boat) for the weekend or for a weeks
holiday in the US.  The example uses COPY FILE to get updates to and from
the notebook using the server, but that's simple enough to achieve using FTP
or similar.  I want to avoid the support work involved in getting a server
solution going - e.g. opening ports for the server - we have enough trouble
with our users' technical support people moving programs and databases
around willy-nilly without adding things like replacing routers ...

2.  How do you get another notebook started later?

The manual says to backup the database before publishing the tables.  Then
restore the tables on the notebook.  But what do you do if you have one
notebook replicating OK and then want to bring another one into the system.
The original backup will probably be way out of date and you wouldn't want
to keep every update file forever.  If you take a current backup and restore
that to the new notebook then the tables are already published, which is
contrary to the instructions in the example.

3rd  question - am I as ignorant as I feel?  Probably YES!

Cheers

Jeff

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz

Jeff,

I can answer 1) and 3)

1. No, you don't need an EDB server. You can use local stores and  it's
up to you how to copy the update files around. Just make sure that the
update files are distributed to the correct stores.

But don't underestimate the comfort of remote stores. Ok, you have to
run a server and open one port - but that's all. No hassle with anything
else.

3. Absolutely NO! When I began to use replication it was quite heavy for
me and I had a lot of questions, now it's just easy to use.

BTW: To avoid new coding for each database I just developed a system
which uses a separate database called "Admin" where all devices
(computers) and databases to replicate are stored. Maybe it's not yet
finished in all details, but I am already using it and it works fine.

Also all procedures to distribute and read update files are stored in
this database which is located on a remote machine. All outgoing update
files are written to one common "out" store. The filenames contain the
devicename and the databasename in order to be filtered by the matching
clients.
On all local machines the same database is installed, but there is just
one record in the devices table: the local computer.

By using this "Admin" database I don't have to rewrite code for
replication of additional databases. Just a record in the devices and
database table will do it.
Each application uses the same code at startup to read and/or write
update files.

If you are interested, I'll share the code.

Best regards Uli

Uli


I haven't started to use replication yet but yes please - share your code.

Roy Lambert

"Uli Becker" <johnmuller54@googlemail.com> wrote in message
news:806F8945-3490-4505-82BF-96E59F57711B@news.elevatesoft.com...
> Jeff,
>
> I can answer 1) and 3)
>
> 1. No, you don't need an EDB server. You can use local stores and  it's up
> to you how to copy the update files around. Just make sure that the update
> files are distributed to the correct stores.
>
> But don't underestimate the comfort of remote stores. Ok, you have to run
> a server and open one port - but that's all. No hassle with anything else.

I fear that my "support" colleague will be very anti having to do things
like opening ports - to much scope for the "blame game" when something goes
wrong and there are multiple tech people involved - so its good to know I
can avoid this if I need to.
..
..
..
> BTW: To avoid new coding for each database I just developed a system which
> uses a separate database called "Admin" where all devices (computers) and
> databases to replicate are stored. Maybe it's not yet finished in all
> details, but I am already using it and it works fine.
>
> Also all procedures to distribute and read update files are stored in this
> database which is located on a remote machine. All outgoing update files
> are written to one common "out" store. The filenames contain the
> devicename and the databasename in order to be filtered by the matching
> clients.
> On all local machines the same database is installed, but there is just
> one record in the devices table: the local computer.
>
> By using this "Admin" database I don't have to rewrite code for
> replication of additional databases. Just a record in the devices and
> database table will do it.
> Each application uses the same code at startup to read and/or write update
> files.
>
> If you are interested, I'll share the code.
>

Thanks for that and both Roy and I are interested in looking at your code


Cheers

Jeff

OK, I posted all scripts and the delphi form in the binaries ng.

If anything is not clear to you, please ask me.

Regards Uli

Jeff,

<< 2.  How do you get another notebook started later?

The manual says to backup the database before publishing the tables.  Then
restore the tables on the notebook.  But what do you do if you have one
notebook replicating OK and then want to bring another one into the system.
The original backup will probably be way out of date and you wouldn't want
to keep every update file forever.  If you take a current backup and restore
that to the new notebook then the tables are already published, which is
contrary to the instructions in the example. >>

This is slightly out-of-date.  Since it was written, the RESTORE DATABASE
statement now allows you to specifically reset the published flag for
tables:

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=RESTORE_DATABASE

However, to answer your general question - you just reduce the scope of what
comprises a snapshot by using scheduled jobs on the main installation.  IOW,
every day you have a job execute that takes a new snapshot using BACKUP
DATABASE and clears out any existing update files from the "outbound" store.
That way, you only accumulate update files for the time period that
encompasses everything since the last snapshot.  You can even adjust this to
your liking, using a weekly snapshot if the data volume is low enough to
allow it.  The snapshot timeframe also depends upon how often you plan on
generating update files using SAVE UPDATES since you don't want to have
100,000+ update files sitting there in a store.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com