Merge Replication structural change

Hi

Created a table User with the fields of Uname varchar(30) and pwd varchar(30) in SQL server 2005.

I need to create a publication and Merge subscription with the below structural changes

User table with the fields of Uname varchar(25) and pwd carchar(30).

The publication table having the Uname varchar(30) but we change this to the subscription table as Uname varchar(25).

Is it possible? If you, please give the details.

Thanks.

Hello,

Is it intended to have different size of Uname? Otherwise, please try to ALTER COLUMN Uname to varchar(25) on the publisher side and this change should be populated to the subscriber side.

Thanks.

This posting is provided AS IS with no warranties, and confers no rights

|||

Hi

Thanks for your reply.

I don't want to change this structural change in publication side. I need this change in subscription side only. so that i keep my Db with original structure and i changed the subscription db with modified structure.

|||as a workaround, you can alter table ..varchar(25), propagate the changes, then set @.replicate_ddl to 0, and alter your table back to varchar(30).|||

Thanks Greg I got some idea from your reply.

If I have only one subscription means this is OK. but I am creating multiple subscription at any time.

Here is my complete requirement.

I have two publications. there is some difference in these two publications.

I am creating subscription from WinMobile device. I configure the publication name there. So that it refer the corresponding publication. These two publications are refer same tables but there is some article changes. I don't want to change the structure in both. I need to change this in one publication and the other one having the same as the DB structure.

The users subscribe the publication at any time. so we are not able to alter the tables each and every time.

Thanks again.

|||I would say you have a design issue then. Replication is used primarily to keep data in sync in multiple locations, if the column sizes must be different between data and source, you can try the workaround I mentioned above or fix your apps so that the schemas are always consistent.|||OK Greg. Thanks.