Timeline for Transactional replication is trying to update a row that does not exist yet. Why?
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 22 at 22:43 | vote | accept | fumblinggravy | ||
| Jul 22 at 18:20 | answer | added | rois | timeline score: 0 | |
| Jul 22 at 3:22 | comment | added | fumblinggravy | I'll like to mark your answer as correct @rois because the log backups running while setting up the replication most certainly played a role in my problem and I hope this answer can help others in the future. | |
| Jul 22 at 3:22 | comment | added | fumblinggravy | I was able to disable the DPM log backups and go through the setup again. This time it looked a lot better! When checking the difference of the PK they were only 1 increment apart, rather than the few thousand when the log backups were running every 15 minutes. Obviously though, even being 1 apart means it got stuck again, so I chatted to the engineering team and apparently this table is highly transient and in the end we made the decision not to replicate this table. | |
| Jul 21 at 21:25 | comment | added | fumblinggravy | Log backups are running every 15 minutes and the backup to Azure takes an hour so a number of log backups occur between the time i backup and create the subscription. I'll turn off log backups and test this and come back to you. Thanks for the tip @rois | |
| Jul 18 at 12:34 | comment | added | rois | Does a log backup run between finishing full backup and adding subscription? It may be in this case the log reader doesn't replicate the insert because the record of it is gone already. This is a long shot though, I admit | |
| Jul 18 at 6:58 | history | migrated | from stackoverflow.com (revisions) | ||
| Jul 18 at 5:53 | history | asked | fumblinggravy | CC BY-SA 4.0 |