Hi,

I’ve the following error message:

---------------
ALTER TABLE [dbo].[AnagraficoAutomezzi]
ALTER COLUMN [CodiceXTrascodifica] varchar(10)
Go

Server: messaggio 4929, livello 16, stato 1, riga 1
Cannot alter table ‘AnagraficoAutomezzi’ because it is being published for
replication.
---------------

This is only part of a script with much more alter table…

How can I lunch the script without this problem?

Thanks for your help!
Giacomo


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Well, you cant alter schema involved in replication all that easily. For
this, you can use sp_addmergecolumn (not certain if the name is correct but
its close). If you post other code samples we can try to see what can be
done


MC


"Giacomo" <no_spam@grazie.it> wrote in message
newsp.tgst4zpwt6znx9@tpprog002.ccvtech.com...
>
> Hi,
>
> I've the following error message:
>
> ---------------
> ALTER TABLE [dbo].[AnagraficoAutomezzi]
> ALTER COLUMN [CodiceXTrascodifica] varchar(10)
> Go
>
> Server: messaggio 4929, livello 16, stato 1, riga 1
> Cannot alter table 'AnagraficoAutomezzi' because it is being published for
> replication.
> ---------------
>
> This is only part of a script with much more alter table.
>
> How can I lunch the script without this problem?
>
> Thanks for your help!
> Giacomo
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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.

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
newsp.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.

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
> newsp.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.
>
>

> 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
>> newsp.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.
>>
>>
>
>