-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial table synchronisation #29
Comments
I get ERROR|Cannot replicate table [dbo].[MonitoringParameter] to destination TestFK because minimum source version 238 is greater than destination version 2 Looking at the code it looks like the SyncInfo is not created because the call to check existance/create is after the above error message is shown which stops the execution. I would be very helpful if the project Wiki said a word on how to go about it. |
If the That said, in your specific case the source DB has already evolved beyond the point where the changes before version 238 have already disappeared from the source's change tracking (see https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-tracking-sql-server). You need to make sure that the replication process is executed periodically before the change retention time window is expired. If you have missed replication window, you will need to restore a backup of the current source in the destination and then make sure that the replication process is executed before the source's next retention window expires. |
Hi,
Thanks for the throught explanation.
I think what I stumbled upon was a bug. Basically if SyncInfo table wasn't
present in the destination database - it wouldn't be created and nothing
would happen.
pozdrawiam
Filip Kierzek
T: +48502304434
…On Tue, 28 Jun 2022 at 19:13, Michael Ganss ***@***.***> wrote:
If the SyncInfo table does not exist (i.e. no successful replication has
been completed yet), the code determines the destination's current version
using the SQL Server function CHANGE_TRACKING_CURRENT_VERSION() which
yields the database's current version from SQL Server's change tracking
point of view. When we execute the replication statements, the version in
the destination database increases, but does not stay in sync with the
version in the source (because we do not execute the exact same steps that
were carried out in the source DB). That's why we need the SyncInfo table
to record the source version that we replicated in the destination.
That said, in your specific case the source DB has already evolved beyond
the point where the changes before version 238 have already disappeared
from the source's change tracking (see
https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-tracking-sql-server).
You need to make sure that the replication process is executed periodically
before the change retention time window is expired. If you have missed
replication window, you will need to restore a backup of the current source
in the destination and then make sure that the replication process is
executed before the source's next retention window expires.
—
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKDNZB3DWCJS5M5D7LJ7JLVRMXEBANCNFSM4JADULFQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I don't think it's a bug but expected behavior. The SyncInfo table is created once the initial replication has been successfully completed. In your specific case I believe this has not happened yet because of the reason I outlined above in the second paragraph. Try restoring a fresh backup in the destination, then run the synchronization process again. |
It would be nice, perform initial table synchronization (maybe optional in config) if the minimal version of the source table doesn't meet the version of the destination.
The text was updated successfully, but these errors were encountered: