A red X appears over the 'replicator monitor'

Using the 'SQL Server Enterprise Manager' before selecting 'push new
subsription' a red X appears over the 'replicator monitor'. I noted the red
cross appears over the folder 'merge agents'. If I look at the 'error
details of the merge agent' it says 'The process could not drop one or more
tables because the tables are being used by other publications.'. The thing
is, I'm not dropping any table, just trying to replicate a table between 3
databases. Why does this error happen?
Thnx for your time
Martin
Martin,
have a look at the tables on the subscriber. It is possible that you are
publishing an article to a subscriber that is itself publishing the article.
By default, replication will try to drop the tabl;e on the subscriber but
will be prevented from doing so. If the error message doesn't mention the
tablename, have a look at: http://support.microsoft.com/?id=312292
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||If Paul's suggestion does not help, it could be that the tables on the
subsciber are inadvertly makrked as replicated. IF the subscribing database
had at one time set up for replication or if the database has been restored
from another server where the database was published, this can happen.
If this is the case then you can use the steps in the following article to
resolve the problem:
PRB: You receive error 3724 when you drop a non-replicated object
http://support.microsoft.com/default.aspx?scid=KB;[LN];326352
Rand
This posting is provided "as is" with no warranties and confers no rights.

A question about clustered indexes forcing rebuild of non-clustered indexes.

So I'm readinghttp://www.sql-server-performance.com/tips/clustered_indexes_p2.aspx and I come across this:

When selecting a column to base your clustered index on, try toavoid columns that are frequently updated. Every time that a column used for a clustered index is modified, all of the non-clustered indexes must also be updated, creating additional overhead. [6.5, 7.0, 2000, 2005]Updated 3-5-2004

Does this mean if I have say a table called Item with a clustered index on a column in it called itemaddeddate, and several non-clustered indexes associated with that table, that if a record gets modified and it's itemaddeddate value changes, that ALL my indexes on that table will get rebuilt? Or is it referring to the table structure changing?

If so does this "pseudocode" example also cause this to occur:

sqlstring="select * from item where itemid=12345"

rs.open sqlstring, etc, etc, etc

rs.Fields("ItemName")="My New Item Name"

rs.Fields("ItemPrice")=1.00

rs.Update

Note I didn't explicitly change the value of rs.fields("ItemAddedDate")...does rs.Fields("ItemAddedDate")=rs.Fields("ItemAddedDate") occur implicitly, which would force the rebuild of all the non-clustered indexes?

Since it's been a while and no one responded, I thought I'd throw my 2 cents in. I'm not sure the link you posted is correct, but it might be. It would depend on whether SQL Server attempts to maintain clustering when you update a clustered index, and I don't know the answer to that. For example, suppose you have a clustered index on name and update someone from "AAAA" to "ZZZZ". This would change his position in the table, which is to say it would change the page number of that row (since it would move from the beginning of the DB to the end), which would mean that all other indexes would have to be updated too.

This depends entirely on whether SQL actually tries to maintain the clustering in real time, and I don't know the answer to that. With other products I've worked with, the DB just lets the data get out of cluster and you have to rebuild them from time-to-time.

|||

I posted this question on sql-server-performance and got a reply:http://sql-server-performance.com/Community/forums/p/23274/132088.aspx#132088

|||

dbland07666:

I posted this question on sql-server-performance and got a reply:http://sql-server-performance.com/Community/forums/p/23274/132088.aspx#132088

And that would be me ..

|||

I figured!