Posted by Dan Guzman on 10/04/06 23:41

> PS. Dan, its MC (Marko Culo) ;).

Oops. Sorry, Marko.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"MC" <marko_culoNOSPAM@yahoo.com> wrote in message
news:eg0r1t$bqq$1@ss408.t-com.hr...
> Just to add something to my previous response. You could try using EM to
> implement some of the changes, however I really wouldnt recommend this.
> Changing schema for database involved in replication isnt something you
> should do lightly.
> Thats why I asked if you could post additional code that doesnt work for
> you
> so we could suggest something.
>
>
> MC
>
> PS. Dan, its MC (Marko Culo) ;).
>
> "Dan Guzman" <guzmanda@nospam-online.sbcglobal.net> wrote in message
> news:i4sUg.1248$NE6.754@newssvr11.news.prodigy.com...
>> One of the downsides to replication is that is complicates subsequent
> schema
>> changes. As ML mentioned, you need to run the appropriate sp_repl* procs
>> instead of ALTER TABLE. The details vary depending on the type of
>> replication and the changes you are making.
>>
>> If your client established replication outside the scope of your normal
>> support agreement, I suggest you have then remove replication so that
>> your
>> normal script can be run and then reestablish replication afterwards.
> It's
>> unreasonable to expect your upgrade script to handle a replicated schema
>> unless you have detailed knowledge of the replication topology.
>>
>> --
>> Hope this helps.
>>
>> Dan Guzman
>> SQL Server MVP
>>
>> "Giacomo" <no_spam@grazie.it> wrote in message
>> news:op.tgt5pk06t6znx9@tpprog002.ccvtech.com...
>> > I've no more code sample to post, it's just a script with some ALTER
> TABLE
>> > to change columns name or type.
>> > We use this script to update client's DB. But one of them use
> replication
>> > and we are always in trouble to update this DB.
>>
>>
>
>

[Back to original message]