Error Message 8144 on Transaction Push Replication

Don,
have you changed the schema on the publisher and
subscriber - please can you check the table definitions.
Perhaps this was a nosync initialization and you created
the procedures by hand and they are now out of sync as
you've altered the columns on the publisher? Depending on
the problem it may be possible to run
sp_scriptpublicationcustomprocs to generate new
procedures and then recreate them on the subscriber if
this is the case. I'd only do this if the schemas are
identical.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Paul,
Thank you so much. The developers were upgrading the publication and got the
error message that Dirc Khan-Evans just posted.
Trying to run ALTER TABLE ... get the error message:
Server: Msg 4929, Level 16, State 1, Line 1
Cannot alter the table 'blah' because it is being published for replication.
I had no choice but to delete the publication. I recreated it and pushed a
new subscription and it ran successfully. However, the schema changes did not
carry over to the subscriber. The subsriber table does not have the new
fields. That is why I am getting this error. Should I delete the table on
the subscriber and push a new subscription? Thanks.
Don
the "Paul Ibison" wrote:

> Don,
> have you changed the schema on the publisher and
> subscriber - please can you check the table definitions.
> Perhaps this was a nosync initialization and you created
> the procedures by hand and they are now out of sync as
> you've altered the columns on the publisher? Depending on
> the problem it may be possible to run
> sp_scriptpublicationcustomprocs to generate new
> procedures and then recreate them on the subscriber if
> this is the case. I'd only do this if the schemas are
> identical.
> HTH,
> Paul Ibison
> (The ONLY sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Don,
I'd reinitialize, but first double-check something in the
publication properties. On the article properties
elipsis, snapshot tab, for name conflicts check that it
says 'DROP the existing table'. When you subscribe, be
sure to leave the default which is to initialize. Then it
should all go fine.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

>
|||Paul,
Just to let you know how the story ended. I tried to reinitialize, but that
also did not work. I ended up droping the tables on the subscriber that had
schemas different from the publisher. I scripted the tables from the
publisher and recreated them on the subscriber. I then had to recreate the
publications and push the subscriptions. It now seems to be running fine.
Just one thought... the publisher is on SQL 2000 sp2 and the subsciber is on
2000 sp3. I don't know if this was a bug. Thanks for all your help.
Don Saluga
Vector Security Inc.
"Paul Ibison" wrote:

> Don,
> I'd reinitialize, but first double-check something in the
> publication properties. On the article properties
> elipsis, snapshot tab, for name conflicts check that it
> says 'DROP the existing table'. When you subscribe, be
> sure to leave the default which is to initialize. Then it
> should all go fine.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Thanks for the update Don - it's always helpful.
Regards,
Paul
"Don" <Don@.discussions.microsoft.com> wrote in message
news:A1286950-DC8C-4DB3-97CC-1C6E06E90565@.microsoft.com...
> Paul,
> Just to let you know how the story ended. I tried to reinitialize, but
that
> also did not work. I ended up droping the tables on the subscriber that
had
> schemas different from the publisher. I scripted the tables from the
> publisher and recreated them on the subscriber. I then had to recreate
the
> publications and push the subscriptions. It now seems to be running fine.
> Just one thought... the publisher is on SQL 2000 sp2 and the subsciber is
on[vbcol=seagreen]
> 2000 sp3. I don't know if this was a bug. Thanks for all your help.
> Don Saluga
> Vector Security Inc.
> "Paul Ibison" wrote: