Showing posts with label replicated. Show all posts
Showing posts with label replicated. Show all posts

Tuesday, March 27, 2012

Changing column length of a replicated table

Can I increase the length of a varchar column of table involved in transactional replication without dropping and recreating publication/subscription?

Any help/short-cuts/undocumented features greatly appreciated.

Regards

Opal

Are you using SQL Server 2005? If so, you can turn on @.replicate_ddl option (set it to 1) for a publication then use regular "ALTER TABLE ... ALTER COLUMN ..." DDL syntax to increase the length of the column, the DDL change will be automatically replicated to subscriber by replication. (@.replication_ddl options is automatically turned on if you use management studio to create the publication)

Hope that helps,

Zhiqiang Feng

|||

Thank you Zhiqiang for your reply, but sorry we're using 2000.

Opal

|||

Sorry there is no easy workaround in SQL Server 2000. The only alternative is that you can use sp_repldropcolumn then sp_repladdcolumn to drop and re-create the column, but that way you will lose all the data for that column.

Thanks,

Zhiqiang Feng

Thursday, March 22, 2012

changing a primary key in a replicated table

Hi

We have a merge publication - I want to change the primary key for one of the tables (add another column to the primary key)

How do I do it ?

Currently there is no data in the table - which I guess might help..

thanks
Bruce

you can try to run the snapshot agent after change the PK to generate the latest snapshot and reinitialize the subsciption.

I'm not sure if it will work.

Cheers,

Justin

|||

After some testing I worked out that we need to:

a) remove it from the publication

b) recreate snapshot

c) change the primary key at our end

d) change the primary key at their end

e) add it back into the publication

f) recreate snapshot

Tuesday, March 20, 2012

changing a datatype

Hi - I want to change the precision/scale on a decimal datatype on a field
which is in a replicated table (merge). I tried to alter the field on the
publisher but I receive a message saying that I can't do this due to the
table being a replicated table.
Anyone know tips on how to do this (without removing replication). Thanks.
Hi Dave,
unfortunately you can't do this in merge.
Have a look at part (b) in this article for a workaround :
http://www.replicationanswers.com/AddColumn.asp
Alternatively you'll have to reinitialize in the case of merge.
Incidentally, this is no longer an issue in SQL Server 2005.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks Paul.
I'll consider re-initialising as I don't have that much data yet and just
conducting tests now anyway. Do I have to pretty much drop replication, do
the changes and start again with merge replication set up?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:e5dKgDhrFHA.1132@.TK2MSFTNGP10.phx.gbl...
> Hi Dave,
> unfortunately you can't do this in merge.
> Have a look at part (b) in this article for a workaround :
> http://www.replicationanswers.com/AddColumn.asp
> Alternatively you'll have to reinitialize in the case of merge.
> Incidentally, this is no longer an issue in SQL Server 2005.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Dave - you don't need to drop replication as such - just the merge
publication.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Changes to data not replicated

I have an application that uses web-based merge replication.My publisher is SQL 2005 and my subscriber is SQL 2005 Express.I control the replication with RMO code.If I make changes to the data in both databases using SQL Server Management Studio Express, my RMO code correctly syncs the two databases.However if I make changes to the data at the subscription through my application, these changes are not picked up by the replication process, even though the changes are present if you check the tables through Management Studio.What would cause these changes to not be recognized?Any ideas would be appreciated.

Hi there,

If you have changed the data in such a way as to stop the triggers from firing then these changes wouldn't be replicated.

This is normally associated with a bulk insert of data using something like a bulk insert but it doesn't sound like you are doing that.

To check if the triggers are firing you could check for the existence of the rowguids in MSMerge_Contents for the rows that you have changed.

|||

Merge replication uses triggers to track changes. First thing to check is if your updates are causing the triggers to fire and the transactions are commiting after updates. Is there any way for you to profile the updates made by your app? Do you know what DMLs your app uses to make the changes? If you can confirm that the triggers are firing then the next thing to check is if replication is picking up the changes. Are there any errors returned by replication? You can look at the replication log file for detailed errors. Replication log file is sqlmergx.log and its default location is %program files%\microsoft sql server\90\com.

thx

Sudarshan

|||

JR-J

Thanks for your resopnse.

I checked the MSmerge_Contents table after making changes to one of my application's tables. There was a row added when I made the changes from within Management Studio, but not when I made a similar change from within my application. So it looks as though my application doesn't cause the triggers to fire. The changes appear in the application's table in both cases.

I'm just using simple INSERT, UPDATE and DELETE statements in stored procedures in my application. No bulk inserts.

|||

Sudarshan,

Thanks for your resopnse.

I checked the MSmerge_Contents table after making changes to one of my application's data tables. There was a row added when I made the changes from within Management Studio, but not when I made a similar change from within my application. So it looks as though my application doesn't cause the triggers to fire. The changes appear in the application's table in both cases.

I'm just using simple INSERT, UPDATE and DELETE statements in stored procedures in my application. No bulk inserts.

I checked the log file you mentioned and it did not show any errors during merge. The merge picks up the data that is entered through Management Studio, but does not pick up the data I enter through my application.

Everything in the replication process except for this one problem, seems to be working as expected. We created the publication in Management Studio. I then create the subscription on the client using RMO, and also run the synchronization using RMO. This is my last hurdle in getting my application to work.

Are there any special security considerations you must consider for the triggers to work. I just seems to me that the INSERT statement from my stored procedures should cause the trigger to fire, just as entering data into the table in SQL Management Studio. I'm new to using triggers, so I may not be that good at understanding what they are doing behind the scenes.

|||

I am still having the same problem with not being able to sync the data entered through my application. I even created a new publication on a new SQL 2005 Server to ensure that the problem was not with the publication/server/permissions. I reproducibly get the same error mentioned in my original post. As this is the only step left in my development and deployment of this application, I am really stuck until I can solve this problem. Does anyone from Microsoft have and suggestions as to how to troubleshoot this issue. I'll bet that the soultion will be a simple comfiguration setting, or something like that, however, I don't have enough experience to know where to look. We also have several other applications that we hope to use replication on, if we can get this problem solved.

Thanks for any help.

|||

Ok so it's pretty clear that the triggers aren't firing for some reason.

Would it be possible for you to use profiler against your database whilst running the app and any of the logs event viewer/sql logs/ merge agent logs?

It might also be worth while ensuring that the triggers are infact in place. If you script out your tables you should see some triggers that look like this attached to the tables that are participating in replication msmerge_ins_<GUID>, msmerge_upd_<GUID>, msmerge_del_<GUID>.

Cheers, James

|||I tried installing profiler on the computer which runs SQL Express 2005, but the install would not allow me to because Express is installed. The triggers are on all of the tables, and they work, as the data I enter directly into the table through Management Studio Express is correctly merged. Its just that for some reason, the triggers either don't fire, or don't operate correctly when I add data to the same tables from my application. The application is a VB.NET application and uses stored procedures which INSERT, UPDATE and DELETE data in the SQL 2005 Express database. All of the stored procedures are working as expected. I'll see if I can attach profiler to my SQL Express database from another server.|||

yes sorry I forgot you had run the inserts etc manually.

if you have the normal client tools elsewhere hopefully you'll be able to connect across using profiler. I assume there are no error messages in the logs for your issues.

Cheers, James

|||

James,

I was unable to get profiler to connect to my subscriber database.

|||

Just a thought.

Do the row GUIDs need to be named RowGUID in each table. My row GUIDs are named according to the subject of the table, but then marked as a row GUID in the column's properties. This must not make a difference, as the triggers seem to work as expected in Management Studio.

Does anyone know if the Table Adapter's in Visual Studio require any special setup to allow the triggers to fire from within the application. I use DataSets/Table Adapters to design my Queries and Data Access Layer.

|||

No they don't need to be named rowguid in order for everything to work.

What problems are you experiencing connecting profiler to your subscriber?

Sorry I don't know anything about Table adaptors so I'll have to leave that to someone else.

|||

I found the problem.

In Visual Studio you must create a connection string to connect to the databases in your application. One of the advanced features of the connection is a parameter called Replication. It has values of True and False. It was set to True, which seemed logical, since I wanted to do replication of the database. However, True means that the application is recognized as a replication agent. Replication triggers do not fire for replication agents. I set the value to false, and now everything works as expected.

Thanks for your help.

sql

Monday, March 19, 2012

Changes not replicated to subscriber

Hi,

I hope you can help me with this.

I am setting up a tranasctional publication with updateable subscriptions using:

use [LIMS_PUBLISHER_TEST]
exec sp_replicationdboption @.dbname = N'LIMS_PUBLISHER_TEST', @.optname = N'publish', @.value = N'true'
GO
-- Adding the transactional publication
use [LIMS_PUBLISHER_TEST]
exec sp_addpublication @.publication = N'LIMS_PUBLISHER_TEST', @.description = N'Transactional publication with updatable subscriptions of database ''LIMS_PUBLISHER_TEST'' from Publisher ''RIVIERA''.', @.sync_method = N'concurrent_c', @.retention = 0, @.allow_push = N'true', @.allow_pull = N'true', @.allow_anonymous = N'true', @.enabled_for_internet = N'false', @.snapshot_in_defaultfolder = N'false', @.alt_snapshot_folder = N'\\RIVIERA\SNAPSHOT', @.compress_snapshot = N'true', @.ftp_port = 21, @.ftp_login = N'anonymous', @.allow_subscription_copy = N'false', @.add_to_active_directory = N'false', @.repl_freq = N'continuous', @.status = N'active', @.independent_agent = N'true', @.immediate_sync = N'true', @.allow_sync_tran = N'true', @.autogen_sync_procs = N'true', @.allow_queued_tran = N'true', @.allow_dts = N'false', @.conflict_policy = N'pub wins', @.centralized_conflicts = N'true', @.conflict_retention = 14, @.queue_type = N'sql', @.replicate_ddl = 1, @.allow_initialize_from_backup = N'false', @.enabled_for_p2p = N'false', @.enabled_for_het_sub = N'false'
GO


exec sp_addpublication_snapshot @.publication = N'LIMS_PUBLISHER_TEST', @.frequency_type = 1, @.frequency_interval = 1, @.frequency_relative_interval = 1, @.frequency_recurrence_factor = 0, @.frequency_subday = 8, @.frequency_subday_interval = 1, @.active_start_time_of_day = 0, @.active_end_time_of_day = 235959, @.active_start_date = 0, @.active_end_date = 0, @.job_login = null, @.job_password = null, @.publisher_security_mode = 1


use [LIMS_PUBLISHER_TEST]
exec sp_addarticle @.publication = N'LIMS_PUBLISHER_TEST', @.article = N'AUD_AUTHORISED_TEST', @.source_owner = N'dbo', @.source_object = N'AUD_AUTHORISED_TEST', @.type = N'logbased', @.description = null, @.creation_script = null, @.pre_creation_cmd = N'drop', @.schema_option = 0x00000000080314DF, @.identityrangemanagementoption = N'manual', @.destination_table = N'AUD_AUTHORISED_TEST', @.destination_owner = N'dbo', @.status = 16, @.vertical_partition = N'false'
GO


I am adding a pull subscription with immediate with queued failover updating using:

/*at the publisher*/
use [LIMS_PUBLISHER_TEST]
exec sp_addsubscription @.publication = N'LIMS_PUBLISHER_TEST', @.subscriber = N'RIVIERA', @.destination_db = N'LIMS_SUBSCRIBER_2', @.sync_type = N'Replication Support Only', @.subscription_type = N'pull', @.update_mode = N'failover'
GO

/*at the subscriber*/
use [LIMS_SUBSCRIBER_2]
exec sp_addpullsubscription @.publisher = N'RIVIERA', @.publication = N'LIMS_PUBLISHER_TEST', @.publisher_db = N'LIMS_PUBLISHER_TEST', @.independent_agent = N'True', @.subscription_type = N'pull', @.description = N'', @.update_mode = N'failover', @.immediate_sync = 1
exec sp_link_publication @.publisher = N'RIVIERA', @.publication = N'LIMS_PUBLISHER_TEST', @.publisher_db = N'LIMS_PUBLISHER_TEST', @.security_mode = 1, @.login = null, @.password = null
exec sp_addpullsubscription_agent @.publisher = N'RIVIERA', @.publisher_db = N'LIMS_PUBLISHER_TEST', @.publication = N'LIMS_PUBLISHER_TEST', @.distributor = N'RIVIERA', @.distributor_security_mode = 1, @.distributor_login = N'', @.distributor_password = '', @.enabled_for_syncmgr = N'False', @.frequency_type = 64, @.frequency_interval = 0, @.frequency_relative_interval = 0, @.frequency_recurrence_factor = 0, @.frequency_subday = 0, @.frequency_subday_interval = 0, @.active_start_time_of_day = 0, @.active_end_time_of_day = 235959, @.active_start_date = 20051117, @.active_end_date = 99991231, @.alt_snapshot_folder = N'\\RIVIERA\TEMP', @.working_directory = N'', @.use_ftp = N'False', @.job_login = null, @.job_password = null, @.publication_type = 0
GO

The publisher, subscriber and distributor all sit on the same server at present.

I can update a table at the publisher and the changes are replicated to the subscriber, I can update at the subscriber and the changes are replicated to the publisher. After a small number of updates the subscriber falls out of sync despite replication monitor saying the changes has been propagated from the publisher to the distributor and on to the subscriber.

If I run the subscription in a queued failover mode- all works well but unfortunately I need immediate updating as the primary method with queued failover.

What am I missing?

Thanks,

Barney

Hi Barney,

>> After a small number of updates the subscriber falls out of sync despite replication monitor saying the changes has been propagated from the publisher to the distributor and on to the subscriber.

Could you be more specific about this part? What kinds of transactions was missing at subscriber? And if you take a look at the history log for the logreader and distribution agent, do you notice any error messages?

Thanks,

-Peng

|||Hi Peng,

Neither the log reader or the distribution agent record an error- using verbose history logging.

I am performing a simple table update of an nVarChar field on a table which does not appear to have user triggers, just a primary key, two foreign keys an unique key.

This is similar to my previous query PostID=152388 which I resolved by using a 'queued failover' update_mode for the subscription.

I do not think transactions are being delayed by latency issues as subsequent replicated transactions are process successfully.

If you have any ideas your input would be much appreciated :o)

Thanks,

Barney|||What happens at the subscriber when you re initialize replication?

You need to be specific about what is happening. i.e.

The change you make (update a field x on table y at the subscriber/publisher), what happens next, and what problem you see at what stage.|||

Hi Barney,

It is strange to me that replication agent doesn't have any errors but subscriber is out-of-sync. So as Mulhall said, probably you need to be very specific. Saying:

1) what do you mean "out of sync"? Is the table update transaction missing at subscriber or the wrong value is updated?

2) Are there any other transactions at publisher or subscriber at the same time?

3) you mentions the table has primary/foreign/unique constraints. Is the nvarchar column involved in these constraints?

It will be great if you illustrate your scenario step by step and as detail as possible.

Thanks,
-Peng

|||Hi Chaps,

Thanks for your help.

I will try to be more detailed.

At the moment I am initialising my subscriber from a backup following the procedure described in Books Online (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/repref9/html/d0637fc4-27cc-4046-98ea-dc86b7a3bd75.htm)

Once my replication topology is up and running (viewing details of the subscription through Replication Monitor shows no replicated transaction pending).

I then begin updating an nVarChar column within a single replicated table. The column in question is not a key or a constraint and does not have a dependent trigger. I am the only user of the databases- other transactions are not occurring at the publisher or subscriber.

The table I am using is populated with 13 records.

I work through the table at the publisher updating the contents of the particular column.

I see these changes propagate through Replication Monitor from the publisher to the distributor and on to the subscriber.

Once the changes have been propagated and are visible at the subscriber I update the same column at the subscriber.

Again I see the changes propagate and the publisher table is updated.

I can perform this cycle four or five times before the subscriber table does not appear to have been updated by the distributor. Replication Monitor confirms the changes have been propagated and the MSReplication_queue table at the subscriber is empty.

If I now try to update the subscriber I receive the following error:
No row was updated
The data in row 6 was not committed
Error Source: .Net SQLClient Data Provider
Error Message: Updateable Subscriptions: Rows do not match between Publisher and Subscriber. Run the Distribution Agent to refresh rows at the subscriber.
Updateable Subscriptions: Rolling back transaction.
The transaction ended in the trigger. The batch has been aborted.

I cannot see an error with the distribution agent.

Thanks for you help,

Barney|||That's much clearer - though I don't see a solution yet;

How are you doing the updates? I'd suggest adding a TRY/CATCH routine to capture the problem.|||Hi Mulhall,

I have perfoming updates by opening the same table from the publisher and subscriber in an instance of SQL Server Management Studio.

I can knock up a quick .NET Try Catch process if you think it will help.

Thanks,

Barney|||

Hi Barney,

Looks like we need to dig more to find out at which point the transaction is lost on the route to subscriber.

1) Run update command at the publisher.
2) Run sp_browsereplcmds on distribution database. Look at the last command to see if the update command has been transferred to the distribution database.

3) Most likely the command in sp_browsereplcmds is calling a stored procedure (created by replication) at subscriber (with name like sp_MSupd_dboXXX). Check the definition of this stored procedure and check if it can correctly update the table.

4) You may also want to run Profiler at subscriber to see if this stored procedure is called or not.

5) Check the data at subscriber to see if the transaction arrives.

Let me know how it goes.
Thanks,
-Peng

|||Hi Peng,

Again, thanks for spending your time investigating this with me, it is much appreciated.

I have worked through your above steps and this is what transpired.

Update command run at the publisher
sp_browsereplcmds shows 5 commands being passed to the subscriber:
sp_MSdel_dbo...
sp_MSins_dbo...
sp_MSupd_dbo...
followed by an update of my audit tabke
sp_MSins_dbo...
sp_MSins_dbo...

The target table is sucessfully amended.

When run at the subscriber
sp_MSins_dbo... (audit table)
sp_MSdel_dbo...
sp_MSins_dbo...
sp_MSupd_dbo...
sp_MSins_dbo... (audit table)
sp_MSins_dbo... (audit table)
sp_MSins_dbo... (audit table)

The target table is sucessfully amended.

I am a little intrigued as to the difference between audit table updates.

I can repeat the above sequence a number of times.

At the point of failure (update at the publisher not seen at the subscriber) sp_browsereplcmds has the same set of entries as listed in the top section:
sp_MSdel_dbo...
sp_MSins_dbo...
sp_MSupd_dbo...
followed by an update of my audit tabke
sp_MSins_dbo...
sp_MSins_dbo...

If if copy the replication commands being actioned according to SQL Profiler and try to run them manually, they say they have completed but do not result in a field update. Looking at the first command in particular sp_MSdel_dbo... I see the command complete successfully but do not see a row be deleted.

Any ideas?

Thanks,

Barney|||Hi Barney,

From your description, looks like sp_MSdel_dbo... doesn't delete the row, in spite of no error message. You can go to the subscriber and take a look at the definition of this stored procedure to see why it didn't delete the row.

If possible, could you post the definition of sp_MSdel_dbo... in this thread (or send it directly to me), together with the the schema of your published table and the DML at publisher?Then I can take a look and see why the SPs don't update the row properly at subscriber.

Thanks,
-Peng|||Hi Peng,

My apologies for not posting earlier.

Here are the stored procedure definition and the table schema.

sp_MSdel_dbo...

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

ALTER procedure [dbo].[sp_MSdel_dboMACHINE]
@.pkc1 int
,@.msrepl_tran_version uniqueidentifier
as
begin
delete "dbo"."MACHINE"
where "MACHINE_ID" = @.pkc1
and msrepl_tran_version = @.msrepl_tran_version
end
GO

SET ANSI_NULLS OFF
GO

SET QUOTED_IDENTIFIER OFF
GO


Table Schema dbo.MACHINE

USE [LIMS_SUBSCRIBER_2]
GO

/****** Object: Table [dbo].[MACHINE] Script Date: 12/13/2005 11:50:05 ******/

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[MACHINE](
[MACHINE_ID] [dbo].[D_ID] NOT NULL,
[TEST_FACILITY_ID] [dbo].[D_ID] NOT NULL,
[IDENTIFIER] [dbo].[D_MACHINE_IDENTIFIER] NOT NULL,
[NAME] [dbo].[D_MACHINE_NAME] NOT NULL,
[MACHINE_TYPE_ID] [dbo].[D_ID] NOT NULL,
[IS_DELETED] [dbo].[D_BOOLEAN] NOT NULL,
[msrepl_tran_version] [uniqueidentifier] NOT NULL CONSTRAINT [DF__MACHINE__msrepl0F4D3C5F] DEFAULT (newid()),
[AUD_UPDATED_BY_ID] [dbo].[D_ID] NULL,
[AUD_UPDATE_TYPE] [dbo].[D_AUD_UPDATE_TYPE] NULL,
[AUD_UPDATED_WHEN] [dbo].[D_TIMESTAMP] NULL,
CONSTRAINT [MACHINE$PK] PRIMARY KEY NONCLUSTERED
([MACHINE_ID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [DB_Data],
CONSTRAINT [MACHINE$UQ$TEST_FACILITY$IDENTIFIER] UNIQUE NONCLUSTERED
([TEST_FACILITY_ID] ASC,
[IDENTIFIER] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [DB_Data],
CONSTRAINT [MACHINE$UQ$TEST_FACILITY$NAME] UNIQUE NONCLUSTERED ([TEST_FACILITY_ID] ASC,
[NAME] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [DB_Data]
) ON [DB_Data]
GO

SET ANSI_PADDING ON
GO

EXEC sys.sp_bindrule @.rulename=N'[dbo].[R_BOOLEAN]', @.objname=N'[dbo].[MACHINE].[IS_DELETED]' , @.futureonly='futureonly'
GO

EXEC sys.sp_bindrule @.rulename=N'[dbo].[R_AUD_UPDATE_TYPE]', @.objname=N'[dbo].[MACHINE].[AUD_UPDATE_TYPE]' , @.futureonly='futureonly'

Please let me know if I have missed anything or if you would like any other details.

I look forward to hearing your thoughts.

Thanks,

Barney|||

Hi Barney,

I setup replication with your schema above. But still can not repro your issue.

As you reported, sp_MSdel_dboMACHINE is executed but doesn't delete any row. Do you know it is due to not be able to find the appropriate row with the specifed MACHINE_ID or the specifed msrepl_tran_version?

If you can post the actual DML you are using, that might be helpful. Do you repro it with only UPDATE? Or there are also INSERT and DELETE?

Thanks,

Changes not replicated to subscriber

Hi,

I hope you can help me with this.

I am setting up a tranasctional publication with updateable subscriptions using:

use [LIMS_PUBLISHER_TEST]
exec sp_replicationdboption @.dbname = N'LIMS_PUBLISHER_TEST', @.optname = N'publish', @.value = N'true'
GO
-- Adding the transactional publication
use [LIMS_PUBLISHER_TEST]
exec sp_addpublication @.publication = N'LIMS_PUBLISHER_TEST', @.description = N'Transactional publication with updatable subscriptions of database ''LIMS_PUBLISHER_TEST'' from Publisher ''RIVIERA''.', @.sync_method = N'concurrent_c', @.retention = 0, @.allow_push = N'true', @.allow_pull = N'true', @.allow_anonymous = N'true', @.enabled_for_internet = N'false', @.snapshot_in_defaultfolder = N'false', @.alt_snapshot_folder = N'\\RIVIERA\SNAPSHOT', @.compress_snapshot = N'true', @.ftp_port = 21, @.ftp_login = N'anonymous', @.allow_subscription_copy = N'false', @.add_to_active_directory = N'false', @.repl_freq = N'continuous', @.status = N'active', @.independent_agent = N'true', @.immediate_sync = N'true', @.allow_sync_tran = N'true', @.autogen_sync_procs = N'true', @.allow_queued_tran = N'true', @.allow_dts = N'false', @.conflict_policy = N'pub wins', @.centralized_conflicts = N'true', @.conflict_retention = 14, @.queue_type = N'sql', @.replicate_ddl = 1, @.allow_initialize_from_backup = N'false', @.enabled_for_p2p = N'false', @.enabled_for_het_sub = N'false'
GO


exec sp_addpublication_snapshot @.publication = N'LIMS_PUBLISHER_TEST', @.frequency_type = 1, @.frequency_interval = 1, @.frequency_relative_interval = 1, @.frequency_recurrence_factor = 0, @.frequency_subday = 8, @.frequency_subday_interval = 1, @.active_start_time_of_day = 0, @.active_end_time_of_day = 235959, @.active_start_date = 0, @.active_end_date = 0, @.job_login = null, @.job_password = null, @.publisher_security_mode = 1


use [LIMS_PUBLISHER_TEST]
exec sp_addarticle @.publication = N'LIMS_PUBLISHER_TEST', @.article = N'AUD_AUTHORISED_TEST', @.source_owner = N'dbo', @.source_object = N'AUD_AUTHORISED_TEST', @.type = N'logbased', @.description = null, @.creation_script = null, @.pre_creation_cmd = N'drop', @.schema_option = 0x00000000080314DF, @.identityrangemanagementoption = N'manual', @.destination_table = N'AUD_AUTHORISED_TEST', @.destination_owner = N'dbo', @.status = 16, @.vertical_partition = N'false'
GO


I am adding a pull subscription with immediate with queued failover updating using:

/*at the publisher*/
use [LIMS_PUBLISHER_TEST]
exec sp_addsubscription @.publication = N'LIMS_PUBLISHER_TEST', @.subscriber = N'RIVIERA', @.destination_db = N'LIMS_SUBSCRIBER_2', @.sync_type = N'Replication Support Only', @.subscription_type = N'pull', @.update_mode = N'failover'
GO

/*at the subscriber*/
use [LIMS_SUBSCRIBER_2]
exec sp_addpullsubscription @.publisher = N'RIVIERA', @.publication = N'LIMS_PUBLISHER_TEST', @.publisher_db = N'LIMS_PUBLISHER_TEST', @.independent_agent = N'True', @.subscription_type = N'pull', @.description = N'', @.update_mode = N'failover', @.immediate_sync = 1
exec sp_link_publication @.publisher = N'RIVIERA', @.publication = N'LIMS_PUBLISHER_TEST', @.publisher_db = N'LIMS_PUBLISHER_TEST', @.security_mode = 1, @.login = null, @.password = null
exec sp_addpullsubscription_agent @.publisher = N'RIVIERA', @.publisher_db = N'LIMS_PUBLISHER_TEST', @.publication = N'LIMS_PUBLISHER_TEST', @.distributor = N'RIVIERA', @.distributor_security_mode = 1, @.distributor_login = N'', @.distributor_password = '', @.enabled_for_syncmgr = N'False', @.frequency_type = 64, @.frequency_interval = 0, @.frequency_relative_interval = 0, @.frequency_recurrence_factor = 0, @.frequency_subday = 0, @.frequency_subday_interval = 0, @.active_start_time_of_day = 0, @.active_end_time_of_day = 235959, @.active_start_date = 20051117, @.active_end_date = 99991231, @.alt_snapshot_folder = N'\\RIVIERA\TEMP', @.working_directory = N'', @.use_ftp = N'False', @.job_login = null, @.job_password = null, @.publication_type = 0
GO

The publisher, subscriber and distributor all sit on the same server at present.

I can update a table at the publisher and the changes are replicated to the subscriber, I can update at the subscriber and the changes are replicated to the publisher. After a small number of updates the subscriber falls out of sync despite replication monitor saying the changes has been propagated from the publisher to the distributor and on to the subscriber.

If I run the subscription in a queued failover mode- all works well but unfortunately I need immediate updating as the primary method with queued failover.

What am I missing?

Thanks,

Barney

Hi Barney,

>> After a small number of updates the subscriber falls out of sync despite replication monitor saying the changes has been propagated from the publisher to the distributor and on to the subscriber.

Could you be more specific about this part? What kinds of transactions was missing at subscriber? And if you take a look at the history log for the logreader and distribution agent, do you notice any error messages?

Thanks,

-Peng

|||Hi Peng,

Neither the log reader or the distribution agent record an error- using verbose history logging.

I am performing a simple table update of an nVarChar field on a table which does not appear to have user triggers, just a primary key, two foreign keys an unique key.

This is similar to my previous query PostID=152388 which I resolved by using a 'queued failover' update_mode for the subscription.

I do not think transactions are being delayed by latency issues as subsequent replicated transactions are process successfully.

If you have any ideas your input would be much appreciated :o)

Thanks,

Barney|||What happens at the subscriber when you re initialize replication?

You need to be specific about what is happening. i.e.

The change you make (update a field x on table y at the subscriber/publisher), what happens next, and what problem you see at what stage.|||

Hi Barney,

It is strange to me that replication agent doesn't have any errors but subscriber is out-of-sync. So as Mulhall said, probably you need to be very specific. Saying:

1) what do you mean "out of sync"? Is the table update transaction missing at subscriber or the wrong value is updated?

2) Are there any other transactions at publisher or subscriber at the same time?

3) you mentions the table has primary/foreign/unique constraints. Is the nvarchar column involved in these constraints?

It will be great if you illustrate your scenario step by step and as detail as possible.

Thanks,
-Peng

|||Hi Chaps,

Thanks for your help.

I will try to be more detailed.

At the moment I am initialising my subscriber from a backup following the procedure described in Books Online (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/repref9/html/d0637fc4-27cc-4046-98ea-dc86b7a3bd75.htm)

Once my replication topology is up and running (viewing details of the subscription through Replication Monitor shows no replicated transaction pending).

I then begin updating an nVarChar column within a single replicated table. The column in question is not a key or a constraint and does not have a dependent trigger. I am the only user of the databases- other transactions are not occurring at the publisher or subscriber.

The table I am using is populated with 13 records.

I work through the table at the publisher updating the contents of the particular column.

I see these changes propagate through Replication Monitor from the publisher to the distributor and on to the subscriber.

Once the changes have been propagated and are visible at the subscriber I update the same column at the subscriber.

Again I see the changes propagate and the publisher table is updated.

I can perform this cycle four or five times before the subscriber table does not appear to have been updated by the distributor. Replication Monitor confirms the changes have been propagated and the MSReplication_queue table at the subscriber is empty.

If I now try to update the subscriber I receive the following error:
No row was updated
The data in row 6 was not committed
Error Source: .Net SQLClient Data Provider
Error Message: Updateable Subscriptions: Rows do not match between Publisher and Subscriber. Run the Distribution Agent to refresh rows at the subscriber.
Updateable Subscriptions: Rolling back transaction.
The transaction ended in the trigger. The batch has been aborted.

I cannot see an error with the distribution agent.

Thanks for you help,

Barney|||That's much clearer - though I don't see a solution yet;

How are you doing the updates? I'd suggest adding a TRY/CATCH routine to capture the problem.|||Hi Mulhall,

I have perfoming updates by opening the same table from the publisher and subscriber in an instance of SQL Server Management Studio.

I can knock up a quick .NET Try Catch process if you think it will help.

Thanks,

Barney|||

Hi Barney,

Looks like we need to dig more to find out at which point the transaction is lost on the route to subscriber.

1) Run update command at the publisher.
2) Run sp_browsereplcmds on distribution database. Look at the last command to see if the update command has been transferred to the distribution database.

3) Most likely the command in sp_browsereplcmds is calling a stored procedure (created by replication) at subscriber (with name like sp_MSupd_dboXXX). Check the definition of this stored procedure and check if it can correctly update the table.

4) You may also want to run Profiler at subscriber to see if this stored procedure is called or not.

5) Check the data at subscriber to see if the transaction arrives.

Let me know how it goes.
Thanks,
-Peng

|||Hi Peng,

Again, thanks for spending your time investigating this with me, it is much appreciated.

I have worked through your above steps and this is what transpired.

Update command run at the publisher
sp_browsereplcmds shows 5 commands being passed to the subscriber:
sp_MSdel_dbo...
sp_MSins_dbo...
sp_MSupd_dbo...
followed by an update of my audit tabke
sp_MSins_dbo...
sp_MSins_dbo...

The target table is sucessfully amended.

When run at the subscriber
sp_MSins_dbo... (audit table)
sp_MSdel_dbo...
sp_MSins_dbo...
sp_MSupd_dbo...
sp_MSins_dbo... (audit table)
sp_MSins_dbo... (audit table)
sp_MSins_dbo... (audit table)

The target table is sucessfully amended.

I am a little intrigued as to the difference between audit table updates.

I can repeat the above sequence a number of times.

At the point of failure (update at the publisher not seen at the subscriber) sp_browsereplcmds has the same set of entries as listed in the top section:
sp_MSdel_dbo...
sp_MSins_dbo...
sp_MSupd_dbo...
followed by an update of my audit tabke
sp_MSins_dbo...
sp_MSins_dbo...

If if copy the replication commands being actioned according to SQL Profiler and try to run them manually, they say they have completed but do not result in a field update. Looking at the first command in particular sp_MSdel_dbo... I see the command complete successfully but do not see a row be deleted.

Any ideas?

Thanks,

Barney|||Hi Barney,

From your description, looks like sp_MSdel_dbo... doesn't delete the row, in spite of no error message. You can go to the subscriber and take a look at the definition of this stored procedure to see why it didn't delete the row.

If possible, could you post the definition of sp_MSdel_dbo... in this thread (or send it directly to me), together with the the schema of your published table and the DML at publisher?Then I can take a look and see why the SPs don't update the row properly at subscriber.

Thanks,
-Peng|||Hi Peng,

My apologies for not posting earlier.

Here are the stored procedure definition and the table schema.

sp_MSdel_dbo...

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

ALTER procedure [dbo].[sp_MSdel_dboMACHINE]
@.pkc1 int
,@.msrepl_tran_version uniqueidentifier
as
begin
delete "dbo"."MACHINE"
where "MACHINE_ID" = @.pkc1
and msrepl_tran_version = @.msrepl_tran_version
end
GO

SET ANSI_NULLS OFF
GO

SET QUOTED_IDENTIFIER OFF
GO


Table Schema dbo.MACHINE

USE [LIMS_SUBSCRIBER_2]
GO

/****** Object: Table [dbo].[MACHINE] Script Date: 12/13/2005 11:50:05 ******/

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[MACHINE](
[MACHINE_ID] [dbo].[D_ID] NOT NULL,
[TEST_FACILITY_ID] [dbo].[D_ID] NOT NULL,
[IDENTIFIER] [dbo].[D_MACHINE_IDENTIFIER] NOT NULL,
[NAME] [dbo].[D_MACHINE_NAME] NOT NULL,
[MACHINE_TYPE_ID] [dbo].[D_ID] NOT NULL,
[IS_DELETED] [dbo].[D_BOOLEAN] NOT NULL,
[msrepl_tran_version] [uniqueidentifier] NOT NULL CONSTRAINT [DF__MACHINE__msrepl0F4D3C5F] DEFAULT (newid()),
[AUD_UPDATED_BY_ID] [dbo].[D_ID] NULL,
[AUD_UPDATE_TYPE] [dbo].[D_AUD_UPDATE_TYPE] NULL,
[AUD_UPDATED_WHEN] [dbo].[D_TIMESTAMP] NULL,
CONSTRAINT [MACHINE$PK] PRIMARY KEY NONCLUSTERED
([MACHINE_ID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [DB_Data],
CONSTRAINT [MACHINE$UQ$TEST_FACILITY$IDENTIFIER] UNIQUE NONCLUSTERED
([TEST_FACILITY_ID] ASC,
[IDENTIFIER] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [DB_Data],
CONSTRAINT [MACHINE$UQ$TEST_FACILITY$NAME] UNIQUE NONCLUSTERED ([TEST_FACILITY_ID] ASC,
[NAME] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [DB_Data]
) ON [DB_Data]
GO

SET ANSI_PADDING ON
GO

EXEC sys.sp_bindrule @.rulename=N'[dbo].[R_BOOLEAN]', @.objname=N'[dbo].[MACHINE].[IS_DELETED]' , @.futureonly='futureonly'
GO

EXEC sys.sp_bindrule @.rulename=N'[dbo].[R_AUD_UPDATE_TYPE]', @.objname=N'[dbo].[MACHINE].[AUD_UPDATE_TYPE]' , @.futureonly='futureonly'

Please let me know if I have missed anything or if you would like any other details.

I look forward to hearing your thoughts.

Thanks,

Barney|||

Hi Barney,

I setup replication with your schema above. But still can not repro your issue.

As you reported, sp_MSdel_dboMACHINE is executed but doesn't delete any row. Do you know it is due to not be able to find the appropriate row with the specifed MACHINE_ID or the specifed msrepl_tran_version?

If you can post the actual DML you are using, that might be helpful. Do you repro it with only UPDATE? Or there are also INSERT and DELETE?

Thanks,

Sunday, March 11, 2012

Change Unique ID to non unique ID in replicated table

Hi,
I have a replicated to table. It has the ID column as unique and I want it
to convert it into non unique. How can I do it?
Exactly what do you mean by non-unique. There are three kinds of indexes,
clustered, non clustered or unique.
Unique means an index or actually a constraint that uses an index, which
ensures unique values and allows a null. A non-clustered index is an index
that is maintained on a seperate database page containing pointers which
point back to where in the table a particular value occurs. A clustered
index orders the data in the table according to a criteria.
To change an index you do this
sp_help tablename and obtain the index name
then drop the index
drop index authors.aunmind
then recreate it (if you want to convert the index to a clustered or
non-clustered index).
I assume you are talking about the table on the subscriber.
If you want to replicate a primary key which occurs on a published table on
the publisher to a primary key on the subscriber right click on yoru
publication, select properties, click the articles tab, and click the three
ellipses next to your article you wish to modify the index on. Then in the
snapshot tab, check include DRI. By default primary keys are replicated as
unique indexes on the subscriber.
HTH
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Vivek" <vivek@.nospam.com> wrote in message
news:uMeeotwjEHA.2908@.TK2MSFTNGP10.phx.gbl...
> Hi,
> I have a replicated to table. It has the ID column as unique and I want
it
> to convert it into non unique. How can I do it?
>
|||Hi Hillary,
Thanks for your reply. I think I should have framed my query differently.
I have a table on publisher with a primary key. What we intend to do is get
rid of the primary key so that we can insert any number and the following
records. Now, how do I can I change the column to be not primary key.
Thanks
Vivek
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%23Dv3VS1jEHA.1520@.TK2MSFTNGP10.phx.gbl...
> Exactly what do you mean by non-unique. There are three kinds of indexes,
> clustered, non clustered or unique.
> Unique means an index or actually a constraint that uses an index, which
> ensures unique values and allows a null. A non-clustered index is an index
> that is maintained on a seperate database page containing pointers which
> point back to where in the table a particular value occurs. A clustered
> index orders the data in the table according to a criteria.
> To change an index you do this
> sp_help tablename and obtain the index name
> then drop the index
> drop index authors.aunmind
> then recreate it (if you want to convert the index to a clustered or
> non-clustered index).
> I assume you are talking about the table on the subscriber.
> If you want to replicate a primary key which occurs on a published table
on
> the publisher to a primary key on the subscriber right click on yoru
> publication, select properties, click the articles tab, and click the
three
> ellipses next to your article you wish to modify the index on. Then in the
> snapshot tab, check include DRI. By default primary keys are replicated as
> unique indexes on the subscriber.
> HTH
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Vivek" <vivek@.nospam.com> wrote in message
> news:uMeeotwjEHA.2908@.TK2MSFTNGP10.phx.gbl...
> it
>
|||You will have to alter the table to drop the constraint
create table primarykey
(pk int not null identity(1,1) primary key)
GO
sp_help primarykey
GO
--scroll down until you see the name of the primary key - in our case its
called PK__primarykey__52AE4273
alter table primarykey
drop constraint PK__primarykey__52AE4273
GO
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Vivek Sharma" <joebloggs@.news.com> wrote in message
news:OV7xLN9jEHA.2412@.TK2MSFTNGP15.phx.gbl...
> Hi Hillary,
> Thanks for your reply. I think I should have framed my query differently.
> I have a table on publisher with a primary key. What we intend to do is
get[vbcol=seagreen]
> rid of the primary key so that we can insert any number and the following
> records. Now, how do I can I change the column to be not primary key.
> Thanks
> Vivek
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%23Dv3VS1jEHA.1520@.TK2MSFTNGP10.phx.gbl...
indexes,[vbcol=seagreen]
index[vbcol=seagreen]
> on
> three
the[vbcol=seagreen]
as[vbcol=seagreen]
want
>
|||Thanks a lot Hilary. It was a great help.
Vivek
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:elqZKECkEHA.384@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> You will have to alter the table to drop the constraint
> create table primarykey
> (pk int not null identity(1,1) primary key)
> GO
> sp_help primarykey
> GO
> --scroll down until you see the name of the primary key - in our case its
> called PK__primarykey__52AE4273
> alter table primarykey
> drop constraint PK__primarykey__52AE4273
> GO
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "Vivek Sharma" <joebloggs@.news.com> wrote in message
> news:OV7xLN9jEHA.2412@.TK2MSFTNGP15.phx.gbl...
differently.[vbcol=seagreen]
> get
following[vbcol=seagreen]
> indexes,
which[vbcol=seagreen]
> index
which[vbcol=seagreen]
clustered[vbcol=seagreen]
table[vbcol=seagreen]
> the
replicated
> as
> want
>

Sunday, February 19, 2012

Change servername based on logon server

Hi
We are to use an application on two replicated sites, the application uses a
user dsn.
We propose to use a reg file attached to a logon script to amend the server
name so that users with laptops can move transparently between sites.
Is this the best method or is there another?
Thanks
BA registry file? Sounds dangerous.
"Ben" <Ben@.Newsgroups.microsoft.com> wrote in message
news:OoEZPKocGHA.1324@.TK2MSFTNGP04.phx.gbl...
> Hi
> We are to use an application on two replicated sites, the application uses
> a
> user dsn.
> We propose to use a reg file attached to a logon script to amend the
> server
> name so that users with laptops can move transparently between sites.
> Is this the best method or is there another?
> Thanks
> B
>|||Hi
Yes the server name is stored in the HKCU.
We use reg files regularly to update other required settings to the HKCU.
But is there a reccomended method?
Thanks
B
"Mike C#" <xxx@.yyy.com> wrote in message news:tAR8g.506$Ut2.358@.fe09.lga...
> A registry file? Sounds dangerous.
> "Ben" <Ben@.Newsgroups.microsoft.com> wrote in message
> news:OoEZPKocGHA.1324@.TK2MSFTNGP04.phx.gbl...
uses[vbcol=seagreen]
>|||That's probably the easiest method, but it would be really easy for some to
alter the reg files and screw up a registry pretty badly. For constantly
changing servers, maybe a File DSN would be a more secure bet? For security
purposes, if you want to mess directly with the registry, maybe adding a
short application to the logon script that only touches the registry keys
you really want to change would be a more secure bet? I'd just be a little
hesitant about installing nondescriminating reg files on user computers.
"Ben" <Ben@.Newsgroups.microsoft.com> wrote in message
news:eLjhcPtdGHA.3364@.TK2MSFTNGP05.phx.gbl...
> Hi
> Yes the server name is stored in the HKCU.
> We use reg files regularly to update other required settings to the HKCU.
> But is there a reccomended method?
> Thanks
> B
> "Mike C#" <xxx@.yyy.com> wrote in message
> news:tAR8g.506$Ut2.358@.fe09.lga...
> uses
>|||Hi Mike,
Thanks for your post, and sorry for the delay in replying, sadly our
Software Vendor only Supports User and System DSNs.
The logon script / reg file is in a secure location on the server where
users do not have write access, it will run on each boot so if the user
messes with the registry: after a boot we are sorted again. Thankfully I
think they all have not even heard of a registry let alone know how to open
regedit :-)
Thanks
B
"Mike C#" <xxx@.yyy.com> wrote in message news:C7t9g.164$yJ6.58@.fe12.lga...
> That's probably the easiest method, but it would be really easy for some
to
> alter the reg files and screw up a registry pretty badly. For constantly
> changing servers, maybe a File DSN would be a more secure bet? For
security
> purposes, if you want to mess directly with the registry, maybe adding a
> short application to the logon script that only touches the registry keys
> you really want to change would be a more secure bet? I'd just be a
little
> hesitant about installing nondescriminating reg files on user computers.
> "Ben" <Ben@.Newsgroups.microsoft.com> wrote in message
> news:eLjhcPtdGHA.3364@.TK2MSFTNGP05.phx.gbl...
HKCU.[vbcol=seagreen]
>|||Hi Ben,
I'd still be concerned that the registry file could be altered at some point
before being installed on the system (a disgruntled IT employee? hacker?
curious employee? who knows...) Of course that's just my initial thoughts,
but I'd be hesitant to send .reg files to be directly imported into the
registry. Personally I prefer the idea of some form of small validating
application called from the script to ensure direct registry updates are
within a very well-defined and narrow scope. In fact, since you're doing
DSNs, I might even go a step further and suggest using the ODBC API to
update them instead of writing the registry directly. Presumably the ODBC
API offers additional validation of the DSN as well (i.e., length of DSN
name, etc.)
Anyway, best of luck!
Mike
"Ben" <Ben@.Newsgroups.microsoft.com> wrote in message
news:OURbJ2qfGHA.4864@.TK2MSFTNGP05.phx.gbl...
> Hi Mike,
> Thanks for your post, and sorry for the delay in replying, sadly our
> Software Vendor only Supports User and System DSNs.
> The logon script / reg file is in a secure location on the server where
> users do not have write access, it will run on each boot so if the user
> messes with the registry: after a boot we are sorted again. Thankfully I
> think they all have not even heard of a registry let alone know how to
> open
> regedit :-)
> Thanks
> B
> "Mike C#" <xxx@.yyy.com> wrote in message news:C7t9g.164$yJ6.58@.fe12.lga...
> to
> security
> little
> HKCU.
>