Posted by MC on 10/04/06 17:29

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]