![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 3 of 3 total |
![]() |
Tue, Nov 4 2008 3:22 PM | Permanent Link |
"David Cornelius" | I almost hate to ask this question and I'm sure I know what the answer
is, but I'm really scratching my head over the problems I'm seeing. The issue involves replication in an environment where four remote people use their own local copy of a database and synchronize periodically throughout the day with a server database. The application assigns unique internal autoinc ID ranges in each of the published tables so that anyone can create a record, synchronize, and get everyone elses additions, changes, and deletions. This is working well for all new records created. A couple of months ago, I converted their old data (which was in FoxPro for DOS) to the new system, but there were some bugs in how I organized the synchronization. To make a long story short, some of the records that were created right after the data conversion, were assigned internal IDs in the range of a test user I had created. I corrected the situation and just left the new records with their IDs, figuring it didn't matter what internal ID was used as long as there were no duplicates. There were also cases where an update process reported an attempt to modify a record that didn't exist; so I manually created the record and re-ran the update to let it go through completely. To make sure there were no duplicates, I created a stored procedure that runs at application startup that restarts the autoinc field of each published table to the last value available in that table for that user's range. That also seems to work. There is one key person that touches everyone's records by performing final billing and shipping functions, prints out a copy for faxing, and eventually marks the record as "closed". As changes are made to the records, we all have been making sure that the changes are replicated to the other users. Again for all newly created records, everything is working fine. The problem is that when she makes changes to the records that were created with the wrong IDs, the changes don't get replicated. I don't think it has anything to do with the actual ID numbers, because she frequently modifies records newly created by other people (which, of course, have different internal autoinc IDs) and we all get the changes. What I am wondering about is if there's some internal flag at the record level that is set or cleared when a record is replicated. I just think it's weird that most records synchronize just fine, but these certain records that had problems a couple of months back, but need changes now, are not getting synchronized when others in the same table are getting synchronized. We've been working around the issue for now by having each person delete their copy of the record, synchronizing, then having one person re-create the troublesome record. Any words of wisdom here would be appreciated! -- David Cornelius CorneliusConcepts.com |
Tue, Nov 4 2008 4:11 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | David,
<< What I am wondering about is if there's some internal flag at the record level that is set or cleared when a record is replicated. >> No, on the internal flag. The only two things that happen are this: 1) A table is published, and all inserts, updates, and deletes to that table are logged along with the publisher ID of the table that performed the modification(s). If the modification(s) are occurring due to a LOAD UPDATEs statement, then the publisher ID of the table performing the modification is added to the internal manifest (list of publisher IDs) for the modification and logged as such. This is done so that EDB can know when a modification has already been loaded by a particular published table, thus preventing it from being loaded again. 2) When a SAVE UPDATES is executed against a particular published table(s), then all logged updates for the table(s) are saved to the updates file and then removed completely. << I just think it's weird that most records synchronize just fine, but these certain records that had problems a couple of months back, but need changes now, are not getting synchronized when others in the same table are getting synchronized. >> More than likely you've got something messed up with the primary keys for the involved tables. The number one reason why an update would not load would be a mismatched primary key. The primary keys must match, or else the replication will not work properly. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Nov 4 2008 5:22 PM | Permanent Link |
"David Cornelius" | > More than likely you've got something messed up with the primary keys
> for the involved tables. The number one reason why an update would > not load would be a mismatched primary key. The primary keys must > match, or else the replication will not work properly. Thanks for the info. I'll double check how the primary keys, autoinc IDs in each person's range, are restarted. I wonder if it's just the first one they create each day... -- David Cornelius CorneliusConcepts.com |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |