Agent is suspect

Any suggests on Agent is suspect error?
MJ
Is the rest of the message concerning no response from backend
connection...? If so, this is an informational message when running a long
batch. I get this on initialization of our largest table when the indexes are
being applied. It isn't really an error - it is a message. you can configure
-KeepAliveMessageInterval to determine if you get these messages.
HTH,
Paul Ibison
|||Hi Paul;
This message is followed by
"The process could not drop one or more tables because the tables are being
used by other publications."
I reviewed all publications and none of them refer to this subscriber.
I reviewed the remote subscriber and the subscription was delivered.
Thanks MJ
"Paul Ibison" wrote:

> Is the rest of the message concerning no response from backend
> connection...? If so, this is an informational message when running a long
> batch. I get this on initialization of our largest table when the indexes are
> being applied. It isn't really an error - it is a message. you can configure
> -KeepAliveMessageInterval to determine if you get these messages.
> HTH,
> Paul Ibison
|||If you are convinced that the table isn't being republished, you can remove
the replication flag. There is a stored procedure to do this called
sp_MSunmarkreplinfo which takes a tablename as a parameter.
HTH,
Paul Ibison
|||In reading other messages I came across one you responded to.
That in says the same.
However I am using SQL Server 2000 and was not able to find
sp_MSunmarkreplinfo.
In an effort to remove the error
"Can not drop table becuse the table is being used by another publication"
I run MSremoveDBreplication on the subscriber side.
I now have a new error messages
"The process could not bulkd copy into MSMerge_tombestone."
"The process could not deliver the snapshot to the subscriber"
"The subscription to publication is invalid"
Thank you for your time
MJ
"Paul Ibison" wrote:

> If you are convinced that the table isn't being republished, you can remove
> the replication flag. There is a stored procedure to do this called
> sp_MSunmarkreplinfo which takes a tablename as a parameter.
> HTH,
> Paul Ibison
|||Thank you Paul;
"Paul Ibison" wrote:

> The sp to use for what you did is sp_removedbreplication, but this is to be
> done as a final cleanup action after dropping replication objects -
> subscriptions in your case. So, I'd drop the subscription then reinitialize.
> HTH,
> Paul Ibison
>
>
|||Wrap Up
The final story to this thread is that the subscriber rebuilt thier box and
renamed it without passing the information on.
Once that information was passed along, everything worked fine.
I thank you and Hillary for all your assistance.
MJ
"Paul Ibison" wrote:

> The sp to use for what you did is sp_removedbreplication, but this is to be
> done as a final cleanup action after dropping replication objects -
> subscriptions in your case. So, I'd drop the subscription then reinitialize.
> HTH,
> Paul Ibison
>
>
|||ok - thanks for the update