SQL Server Replication - Duplicate subscription agents? - sql-server-2005

I am new to SQL Server replication, and pushed some changes out to an existing replicated environment. It is SQL Server 2005 SP3, with Transactional replication.
I created a new table, added columns to an existing table, and added some SPs. I did all of this on the publisher database.
I created a new snapshot and reinitialized the subscriptions. The new table and new columns were replicated to the new server, and data was synchronized successfully, but just 1 time.
Immediately after, the replication monitor is reporting an error. On the Distributor to Subscriber History tab, I get a message that the "Subquery returned more than 1 value". The Command Attempted is...
delete from MSsubscription_articlecolumns
where artid=89 and
agent_id = (
select id from MSsubscription_agents
where update_mode > 0 and
UPPER(publisher) = UPPER('xxxx') and
publisher_db = N'xxxx' and
publication = N'xxxxx'
) end
Why would there be duplicate subscription agents? How do I fix this? Thanks for all help.

I was able to resolve the issue by manually editing the data in the MSsubscription_agents table. There were 2 records with the same publisher, db and publication names. Instead of deleting one of the records, I changed the update_mode on the older record to be 0, which filtered it out of the problem statement in original question. The replication process was then able to get past that statement and run correctly. Thanks.

Related

Log who deleted a row using Change Data Capture

I have SQL 2014 Enterprise and have configured Change Data Capture (CDC). I have UserId columns on all of my tables. So CDC does a great job seeing who inserted and updated a row but if someone deletes a row I cant see who deleted the row (it has the previous UserId in the row). I know Oracle has this feature included in their CDC package.
Create a trigger after delete which stores the userid of whoever deleted the data. you'd want to have a table setup that has restricted access, likely to the admin, to store the information.

Merge replication error the schema script could not be propagated to the subscriber SQL Server 2008

I am with replication so after trying for 1 month I am able to initialize publisher on remote system and subscriber on my local system. When I run job at subscriber end I get an error
the schema script AccountNotic1234.sch could not be propagated to the subscriber
Somewhere I read this error happens when tables are connected using foreign keys and you missing primary table but I am synchronizing all tables. So it can not be the issue.
When I run the subscription I get error for 3 tables in order not on 1st and 2nd don't know why?
What can be the possible reasons for this?

SQL Server - mirror some columns from tables to another database on the same server without replication

I have a SQL Server 2012 Web Edition (11.0.5058.0) instance on a VPS which hosts two databases. I would like to mirror a couple of columns from 3 tables to the second database, but I don't have transactional replication installed.
So I have a Staff table on the source database - I just want the staff_code and unique_id - I have an Activity table - I just need the activity_code, description and unique_id.. etc.
What is the best way to go about this - would that be triggers? The data is not regularly updated, possibly once a week - but I would still like the synchronisation to be fast if possible?
The data in the source database may be deleted, updated or inserted, by another application, so I want to ensure the data in my database reflects that information correctly.
Thanks for any suggestions!
UPDATED: Table comparison example:
SELECT CASE WHEN NOT EXISTS
( SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [SOURCE-DATABASE].[dbo].[SOURCE-TABLE]
EXCEPT
SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [DESTINATION-DATABASE].[dbo].[DESTINATION-TABLE]
)
AND NOT EXISTS
( SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [DESTINATION-DATABASE].[dbo].[DESTINATION-TABLE]
EXCEPT
SELECT [COLUMN1],[COLUMN2],[UNIQUE_ID] FROM [SOURCE-DATABASE].[dbo].[SOURCE-TABLE]
)
THEN 'True'
ELSE 'False' //GRAB NEW OR UPDATED DATA
END AS result ;
As long as the two databases can be connected (e.g. can you do a SELECT * FROM SecondDB.dbo.Activity?), then I would just
set up a query (stand-alone, or in a stored procedure) that just checks whether or not the data on the source has changed
updates the second database using normal SELECT, INSERT, UPDATE and possibly DELETE statements
set up that query/stored procedure with a SQL Server Agent Job to run at regular intervals, e.g. once every night, once every week - whatever works for you
I don't think triggers would be a good choice here - triggers should be kept very small, lean, fast - and "replicating" to another database sounds like too much processing work for a nimble trigger.... (also if you triggers take a long time to complete, the calling application will have to wait for that whole time..... not good for your application performance!)

Adding new article to transactional replication gives error at subscriber

I have an updatable transactional replication set with SQL Server 2008. Everything is working fine. I added a new table to the existing publication thru sp_addarticle followed by sp_addsubscription. After that I ran the snapshot agent. Snapshot has been generated only for newly added table. So the new table was successfully replicated to subscriber. I could even able to replicate a newly inserted record into new table to subscriber. But vice versa is not possible. When I insert a record into new table in the subscriber database, I am getting an error
*Msg 515 'Cannot insert the value NULL into column 'msrepl_tran_version',
table Servername.dbo.Tablename'; column does not allow nulls. INSERT fails.'*.
Please help me to resolve this issue.
Many Thanks in advance. Geeta
Is it reproducible error? Is subscriber configured as Immediate Updating? In case of Immediate Updating subscriber the transaction fails whenever publisher (or network) is unavailable.
Check and change, if it does not have it, your table so that ms_repl_tran_version defaulted to GUID:
ALTER TABLE [dbo].[TableName] ADD
CONSTRAINT [DFLT_GUID_msrepl] DEFAULT (newid()) FOR
[msrepl_tran_version]

Bidirectional replication update record

I would like to present you my problem related to SQL Server 2005 bidirectional replication.
What do I need?
My teamleader wants to solve one of our problems using bidirectional replication between two databases, each used by different application. One application creates records in table A, changes should replicate to second database into a copy of table A. When data on second server are changed, then those changes have to be propagated back to the first server.
I am trying to achieve bidirectional transactional replication between two databases on one server, which is running SQL Server 2005. I have manage to set this up using scripts, established 2 publications and 2 read only subscriptions with loopback detection. Distributtion database is created, publishment on both databases is enabled. Distributor and publisher are up. We are using some rules to control, which records will be replicated, so we need to call our custom stored procedures during replication. So, articles are set to use update, insert and delete custom stored procedures.
So far so good, but?
Everything works fine, changes are replicating, until updates are done on both tables simultaneously or before changes are replicated (and that takes about 3-6 seconds). Both records then end up with different values.
UPDATE db1.dbo.TestTable SET Col = 4 WHERE ID = 1
UPDATE db2.dbo.TestTable SET Col = 5 WHERE ID = 1
results to:
db1.dbo.TestTable COL = 5
db2.dbo.TestTable COL = 4
But we want to have last change winning replication. Please, is there a way to solve my problem? How can I ensure same values in both records? Or is there easier solution than this kind of replication?
I can provide sample replication script which I am using.
I am looking forward for you ideas,
Mirek
I think that adding dateUpdated field on both tables could help. This way in your replication code a record would be updated only if dateUpdated is greater then the one already stored.
That dateUpdated field would obviously store the datetime when the original record was updated, not when the replication was performed