Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 4 of 4 total |
Replication Issue |
Sun, Jun 14 2009 10:08 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |