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.itwrote in message
news:op.tgst4zpwt6znx9@.tpprog002.ccvtech.com...
Quote:
Originally Posted by
>
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/
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.itwrote in message
news:op.tgt5pk06t6znx9@.tpprog002.ccvtech.com...
Quote:
Originally Posted by
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.
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.netwrote in message
news:i4sUg.1248$NE6.754@.newssvr11.news.prodigy.com ...
Quote:
Originally Posted by
One of the downsides to replication is that is complicates subsequent
schema
Quote:
Originally Posted by
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
Quote:
Originally Posted by
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.itwrote in message
news:op.tgt5pk06t6znx9@.tpprog002.ccvtech.com...
Quote:
Originally Posted by
I've no more code sample to post, it's just a script with some ALTER
TABLE
Quote:
Originally Posted by
Quote:
Originally Posted by
to change columns name or type.
We use this script to update client's DB. But one of them use
replication
Quote:
Originally Posted by
Quote:
Originally Posted by
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.comwrote in message
news:eg0r1t$bqq$1@.ss408.t-com.hr...
Quote:
Originally Posted by
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.netwrote in message
news:i4sUg.1248$NE6.754@.newssvr11.news.prodigy.com ...
Quote:
Originally Posted by
>One of the downsides to replication is that is complicates subsequent
schema
Quote:
Originally Posted by
>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
Quote:
Originally Posted by
>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.itwrote in message
>news:op.tgt5pk06t6znx9@.tpprog002.ccvtech.com...
Quote:
Originally Posted by
I've no more code sample to post, it's just a script with some ALTER
TABLE
Quote:
Originally Posted by
Quote:
Originally Posted by
to change columns name or type.
We use this script to update client's DB. But one of them use
replication
Quote:
Originally Posted by
Quote:
Originally Posted by
and we are always in trouble to update this DB.
>>
>>
>
>
No comments:
Post a Comment