Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 4 of 4 total
Thread Replication Issue
Sun, Jun 14 2009 10:08 AMPermanent Link

Alfred Ghazzi
Hi

I’m having a design issue with replication. Any assistance will be very much appreciated…

The actual organization structure is more complex than the scenario I’m describing below, but it will help me to understand what I'm doing wrong...

On a Server PC:
·   A head office server has been installed
·   A Database and all its related tables and other objects have been created.
·   Published the database
·   Created a backup without a catalog for user 1

On a User  1 PC:
·   Database software is installed.
·   An identical database with all its tables and other objects are created (identical in table structure, but not necessarily in triggers, functions,
etc…)
·   Published the database
·   Restore the backup generated from the server without a catalog.
Restore failes. (even if I manually copy the tables from server database to user database, I get similar error)

I get an error related to “Internal table version being different” and the tables do not open.

Please can you tell me what I’m doing wrong? Is it the structures of the database that must be 100% identical, or should I publish after restore?

Where the Publish IDs are stored? In Configuration file or the Catalog file?

Kind Regards

Alfred
Mon, Jun 15 2009 1:29 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Alfred,

<< I get an error related to “Internal table version being different” and
the tables do not open.

Please can you tell me what I’m doing wrong? Is it the structures of the
database that must be 100% identical, or should I publish after restore? >>

Your error is related to when you're doing the backup, and how you're doing
the backup.  The original procedure should look like this:

On a Server PC:
· A head office server has been installed
· A Database and all its related tables and other objects have been created.
· Created a backup *with* a catalog for user 1
· Published the database

However, if you don't want the same triggers and functions for the server
database catalog as you do for the remote user database catalogs, then
you're going to need to populate the initial data using something other than
a backup/restore (import/export or INSERT SQL statements, etc.), or you're
going to need to restore the database from the server first, and then alter
it so that the database matches the necessary requirements for the remote
user in terms of triggers and functions, etc.  You won't be able to reliably
use a backup/restore without including the catalog on two different
databases since the internal table structure versions may not ever match,
and even if they do, you wouldn't want to rely on such a situation.  For
example, something as simple as adding a different number of indexes to a
table could cause the table version number to be different.

<< Where the Publish IDs are stored? In Configuration file or the Catalog
file? >>

In the database catalog file.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Jun 16 2009 6:45 AMPermanent Link

Alfred Ghazzi
Hi Tim

Thank you very much for your reply....

If I got it right, what you are saying, is that any modifications to objects controlled by the catalog file will change the internal version of the
tables. Accordingly, and obviousely, backups without the catalog could end up being disastrous...

Now, since I cannot send the catalog with the backup becuase:

A. There are some table and non-table related structure differences between the two databases (Table fields are identical but not the triggers
for example)
B. The Publish IDs must stay different (since they are stored in the catalog file).

Accordingly, I should not use a backup to perform the initial population of the user database with data from server database. (It works for
initail users before publishing the server database, but won't work for future users, i.e. after publishing the database).

Accordingly, I should use Export/Import instead of Backup/Restore... Did I get the reasoning right?

On another note, I have a lot of suggestions to make which I believe will make the product even more fantastic... I'll send them later after
signing off this project....

Many Thanks and Kind Regards

Alfred
Tue, Jun 16 2009 1:45 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Alfred,

<< Accordingly, I should use Export/Import instead of Backup/Restore... Did
I get the reasoning right? >>

Yes.  However, you can still use the stores functionality in EDB to transmit
the export files to the clients, just like you would with a backup file or
update file.

<< On another note, I have a lot of suggestions to make which I believe will
make the product even more fantastic... I'll send them later after signing
off this project.... >>

Great, please do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image