Tim,

I start testing replication in EDB2.03b8. I use your technical article "Building a Sales
Qute Replication System in Elevate DB" as a template for my application.
At the beginning I have added only 1 Salesperson to replicate. All works fine so far. Then
I have hired a new salesman and give him connection to the server. I run the scripts
to give the data to the new salesman. Works also fine - but I see, that Salesperson 2 miss
the changes that was made by Salesperson 1 (before Salesperson2 was added).

Is that correct?

How can I add a new Salesperson at a later date, and give this salesperson all the data he
have to had?

Regards
Michael

Michael,

<< Is that correct? >>

No, if you apply all of the update files against Salesperson 2 that were
applied to the other salespersons, then Salesperson 2 should be completely
in-sync with the database.

Did you apply all of the same update files to Salesperson 2 that you applied
to the other salespersons ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

as I understand how the replication process works in elevate I have manually copy the
changes since publishing the main DB to a new clients IN-store. Is that correct?

e.g.:

1. I have 1 replication client in my main DB table. I backup main DB and publish it.
2. If there was changes in the main DB they will be copied to my Server_Updates store and
the Client_Out store if I start the synchronisation at main DB.
3. Now I insert a new replication client in my main DB table. This creates the IN and OUT
stores on main DB.
4. If I now setting up the replication on my new replication client PC, then the script
will only restore the backup that I made in step 1. Not the server updates, that was made
in step 2.

So my new replication client is not in sync correct?

Can you please explain me again how I have to do this process correctly?

Regards
Michael



"Tim Young [Elevate Software]" wrote:

Michael,

<< Is that correct? >>

No, if you apply all of the update files against Salesperson 2 that were
applied to the other salespersons, then Salesperson 2 should be completely
in-sync with the database.

Did you apply all of the same update files to Salesperson 2 that you applied
to the other salespersons ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< 1. I have 1 replication client in my main DB table. I backup main DB and
publish it.
2. If there was changes in the main DB they will be copied to my
Server_Updates store and the Client_Out store if I start the synchronisation
at main DB.
3. Now I insert a new replication client in my main DB table. This creates
the IN and OUT stores on main DB.
4. If I now setting up the replication on my new replication client PC, then
the script will only restore the backup that I made in step 1. Not the
server updates, that was made in step 2. >>

Correct.  However, this is easy to resolve - just copy any additional update
files that were created *after* the intial backup into the Client_Out store
during the step where you copy the backup file into the Client_Out store.
The creation dates are stored in the actual update files themselves, and so
will be accurate down to the millisecond and can be relied upon to properly
determine the correct updates files needed to "catch-up" the new client.

Something like this will work:

SCRIPT
BEGIN
  DECLARE UpdateCursor CURSOR FOR UpdateStmt;
  DECLARE UpdateFile VARCHAR DEFAULT '';
  DECLARE BackupTime TIMESTAMP;

  USE Configuration;

  -- Get the backup date/time

  EXECUTE IMMEDIATE 'SET BACKUPS STORE TO "ServerUpdates"';

  PREPARE UpdateStmt FROM 'SELECT * FROM Backups ORDER BY CreatedOn DESC';
  OPEN UpdateCursor;

  FETCH FIRST FROM UpdateCursor (CreatedOn) INTO BackupTime;

  -- Get a list all of the update files that have been created since
  -- the initial backup and copy them all into the client "out" store

  EXECUTE IMMEDIATE 'SET UPDATES STORE TO "ServerUpdates"';

  PREPARE UpdateStmt FROM 'SELECT * FROM Updates
                           WHERE CreatedOn >= ?
                           ORDER BY CreatedOn';
  OPEN UpdateCursor USING BackupTime;

  FETCH FIRST FROM UpdateCursor (Name) INTO UpdateFile;

  WHILE NOT EOF(UpdateCursor) DO

     -- Copy each update file to the client "out" store

     EXECUTE IMMEDIATE 'COPY FILE "' + UpdateFile + '.EDBUpd" IN STORE
                       "ServerUpdates" TO "' +
                       UpdateFile + '.EDBUpd" IN STORE
                       "Client_Out"';

     FETCH NEXT FROM UpdateCursor (Name) INTO UpdateFile;

  END WHILE;
END

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

ok sounds good.

So I will do following now:

1. Copy backup file from remote store to local SETUP store
2. Use your script to copy all update files from remote store to local IN store
3. run restore database to restore file from step 1
4. run load updates for all files from step 2
5. And at least publish the local database

At the moment I run only step 1, 3, 5 so I miss the changes.

Is it correct, that I have to load the updates before the local database is published?

Regards
Michael

Michael,

<< Is it correct, that I have to load the updates before the local database
is published? >>

Yes, that is correct.  You won't want the updates to try and get sent back
to the source again, although it won't hurt if they are sent because the
source database will just ignore them.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

now I have changed my replication process as you explained me with the script.
The copy of the ServerUpdates works fine, but when I will load the updates an exception is fired.

this is the entry in the callstack:
edbcomps.TEDBSession.Execute('LOAD UPDATES FOR DATABASE "pro-Report 2"'#$D#$A'    FROM "prpServer-2010-02-12 12-03-47.0640" IN STORE "MICK_IN"'#$D#$A,nil,$169CB730)

This is the exception:
---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt prorep2.exe ist eine Exception der Klasse EEDBException mit der Meldung 'ElevateDB Error #300 Cannot lock the configuration EDBConfig for write access' aufgetreten.
---------------------------
Anhalten   Fortsetzen   Hilfe   
---------------------------

regards
Michael

Michael,

<< Im Projekt prorep2.exe ist eine Exception der Klasse EEDBException mit
der Meldung 'ElevateDB Error #300 Cannot lock the configuration EDBConfig
for write access' aufgetreten. >>

That's an error that occurs when the configuration is trying to be updated.
Are you executing any DDL statements (CREATE, ALTER, DROP) for any
configuration objects, such as jobs, etc. ?

Can you send me something that reproduces this ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<That's an error that occurs when the configuration is trying to be updated.
Are you executing any DDL statements (CREATE, ALTER, DROP) for any
configuration objects, such as jobs, etc. ?>

I don´t know which changes are reported in this update files. But it is possible, that there was alter statements. But why is it not possible to execute them?

Sorry, I´m not able to create a little sample to reproduce it. Is it helpful if I will send this update files?

Regards
Michael

Michael,

<< But it is possible, that there was alter statements. But why is it not
possible to execute them? >>

I don't know, which is why I asked for a sample.  A configuration update
with a CREATE, ALTER, or DROP is a one-off execution and does not hold locks
for very long at all.

<< Sorry, I´m not able to create a little sample to reproduce it. Is it
helpful if I will send this update files? >>

No, the update files won't help.  What I need to see is the actual code or
SQL that you're executing.

Is the problem at least reproduceable ?

--
Tim Young
Elevate Software
www.elevatesoft.com