twgonder
Member
- Local time
- Today, 18:16
- Joined
- Jul 27, 2022
- Messages
- 178
I just saw your post after submitting mine (#20). Yes, we've had this discussion before, and I'm aware of all the points you made. Despite that I remain without a solution that I am comfortable with. I've tackled some of your points on requirement, unknowingly, in post #20. I also did a lot of code/design testing over the course of three weeks on just this.We've had this discussion before on AF - in summary
Depending on the requirements of your app - syncing 1 or 2 ways and/or for new data only, and/or to include changes in existing data and /or deletions will dictate what fields you need to manage the syncing process.
- you can use a multi field PK but that gets messy for multiple related tables (customer>invoice header>invoice line> etc).
- ...
I'm not so trusting that random keys won't duplicate if created at different times. I'm going to modify your great little test in post #11 to test for this. But, one has to consider multiple BEs all creating records in several tables over the course of several years. The only way I can think to overcome this is with the old method I used of a "Server code" (like 201 for Store 1 BE) and a sequential number combined to make a system wide key for each table. That's a guarantee there will never be a clash (I never had one in 20+ years and millions of transactions) even when the sequential seed was "lost/corrupted" (simple high/low iterative test to find where to begin anew).
Your db in post #11 is most welcome. It answers several different questions (and created new ones) that have "bugged" me the past few months. Thank you.