I have SQL Server 2005 running on a Windows 7 machine that is replicating data being logged into SQL Server 2005 on a Windows XP machine. I'm having a problem that when subscriptions are dropped, about 1% of the time (works out to about once a month) the corresponding row doesn't get removed from the MSarticles table, leaving a 'ghost' subscription.
A lot of the table structure was set up by the software manufacturer, and I'm not able to change it without breaking the software's job of logging all our sensor records every 10 seconds.
To keep the replication on the currently active set of tables (why the software people set up rotating tables is beyond me) I have a trigger that, when the software moves to the next table in the rotation (which it does every two days):
- Removes the clustered index created by the software
- Adds a primary key (since replication can't be done on a table without one)
- Adds a subscription to the newly active table with
sp_addarticle
andsp_addsubscription
(this won't start replicating until the snapshot agent is run) - Drops the replication on the table being rotated out with
sp_dropsubscription
andsp_droparticle
- Removes the primary key from the older table
- Adds the clustered index to the older table (so the software will interact with it correctly when it comes around again in the rotation)
- Checks a value in a one-row table; if the value is less than 7 (the number of active tables; they are all moved in the rotation at the same time) it increments the value; if equal to 7 it resets the value to 1 and runs the snapshot agent
The ghost rows in the MSarticles table cause an error when removing the primary key, which causes the entire trigger to be rolled back, and then the replication is not backing up everything we need it to be backing up. I've been manually deleting the ghost rows as I notice them and updating all the affected tables that got missed in the replication, which is not ideal.
Two questions:
- Any ideas on why the ghost rows are getting left in the MSarticles table and how to prevent that?
- Would it be an OK workaround to add a step in my trigger to run a
DELETE... WHERE destination_object = 'MyTableName'
statement on the MSarticles table to delete any potential ghost rows? (This would be after runningsp_droparticle
and before removing the primary key; I haven't tried this yet because I'm a little hesitant to set up something that messes with system tables on a recurring and unattended schedule. And also I'm not sure how to reference the MSarticles table on the distributor - the Win7 machine - from the publisher where the trigger is running - the WinXP machine; I can probably figure it out but would rather try to prevent the ghost rows before tackling this workaround.)