![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 2 of 2 total |
![]() |
Mon, Mar 12 2012 12:53 PM | Permanent Link |
Adam Brett Orixa Systems | With a replication database, with 1 server and several local computers, each updating to the server using "SAVE UPDATES" does the engine care about subtle differences in the database structures.
Obviously differences of types / numbers of Tables / Fields would cause conflicts. However, say that there are differences at the level of items such as Indexes, Triggers, Functions ... does the update fail if it sees _any_ differences at all in the data structures between the databases on each "side" of the update, or does it "try its best" to do the update & just fail on particular points? -- As a follow up question: If I need to make updates to a database structure with a replicated database, presumably I need to pause the UPDATE process while such structural changes take place for all the individual "nodes" of the replication system. I have some issues with doing this, as most of the update process is controlled by the "nodes" (pc laptops) not from the server ... I guess I might need to create some sort of check / test by the laptop of the status of the server prior to UPDATEs running so I can block UPDATEs from running when a structural change is taking place. |
Tue, Mar 20 2012 12:44 PM | Permanent Link |
Adam Brett Orixa Systems | OK: In the absence of comments from others
![]() I thought I would post up what I have done in case others want to have a tiny little test case DB to work with. -- Basically, what I have found is that Elevate happily replicates TABLES even from databases with different structures, so long as the structure of the table is identical. i.e. you can have databases which are substantially different from each other but so long as the TABLE you are replicating has the same fields in the same order, and primary keys are all unique the replication will not fail. You can even have different INDEXES, VIEWS and TRIGGERS on your target table and replication still seems to work OK. Replication updates can fail if CONSTRAINTS create conditions that are not met by in-coming records. In this case the WHOLE update fails, i.e. if 10 records are changed & 1 field on 1 record fails a constraint then all 10 changes do not carry over. ... All sensible ... but good really really know & understand if you want to use Replication. It is only when the physical structure of the tables differs that the replication process fails. Attachments: EDB Replication Tests.zip |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |