sql server replication: It's potentially less processing time - largely depends on the 'width' of
your table, ie for a table not especially wide then I'd do the drop method.
if I had 200 columns, I'd do the column technique.
Cheers,
Paul Ibison

Hi,
In BOL there is reference only to sp_repladdcolumn and sp_repldropcolumn
(add and drop), but nothing about altering a column, or have I missed it?
I have to change the collation of a column (that belongs to a table that is
transactionally replicated ) from sensitive to insensitive. Is the only way
to do that is to:
1 - add a New column with the correct collation (sp_repladdcolumn )
2 - copy the data from the old column into the New column (update statement)
3 - drop the old column (sp_repldropcolumn)
Any better way? or have I missed anything?

Thanks

Hi Paul,

right, since add comes before drop, I would need 2 pairs of (add, drop ) ;
the first to alter the collation, the second to alter the column name (to
set it back to the original name) - correct?
and probably to have these 4 sp_Replxxx bracketed by Begin Tran - Commit
Tran.
is the alternative you indicated better in some ways (safer, faster, ...) ?

Thanks


[quoted text, click to view]

Thank you very much !


[quoted text, click to view]

You didn't miss anything - that's a problem we all have faced at some time
or other :). Actually there's another level of iteration you missed out, as
your table will be missing the column with the oldname, so if this is to be
maintained you have to do the whole process again. There is an alternative
of dropping the subscriptions to the table, removing the table from the
publication, altering the table then readding to the publication then adding
subscriptions to this table. In this way you can effectively reinitialize on
a table basis. All MUCH easier in SQL Server 2005 of course - the Alter
Table statement will itself be sufficient for most things.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Ramadan,
please check to see if there is an automatic virus-scanner set up. If so,
disable scanning of the repldata folder.
Also, check that there is space in the distribution working folder to create
the file.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Hi Paul,

Now I am in troubleshooting mode :(



I dropped the subscriptions to the table to alter, dropped the article (tale
from the publication), altered the table, added the article back to the
publication, and added the subscriptions to the publications. The schema
changes to the table became effective and were replicated to the destination
table (in the subscription), but the snapshot agent failed when I ran it.

The error is: The process could not create file.....

I searched on MS and found a couple items (285997, 821480), but I am not
sure.

Any ideas?



The details:

I have 3 publications, each has few articles. There is one subscriber, and
only one subscription to all publications.

I did the following,

EXEC sp_dropsubscription @publication = 'Pub_2'
, @article = 'Orders_2'
, @subscriber = 'SubscriberServer'
, @destination_db = 'Dest_DB'

EXEC sp_droparticle @publication = 'Pub_2'
, @article = 'Orders_2'

ALTER TABLE Orders_2 ALTER COLUMN .....

EXEC sp_addarticle @publication = 'Pub_2'
, @article = 'Orders_2'
, @source_table = 'Orders_2'
, @destination_table = 'Orders_2'
, @force_invalidate_snapshot = 1

-- the next is from scripting out the publication (prior to making the
changes)
EXEC sp_addsubscription @publication = N'Pub_2'
, @article = N'all'
, @subscriber = N'SubscriberServer'
, @destination_db = N'Dest_DB'
, @sync_type = N'automatic'
, @update_mode = N'read only'
, @offloadagent = 0
, @dts_package_location = N'distributor'


[quoted text, click to view]

Hi Paul,
it was as simple as a missing folder could be.
Thank you very much for your help.


[quoted text, click to view]