No errors. No replication, either...

I have one central publisher server and several remote merge pull boxes. On random remote servers, at random times, replication will fail. The data is inconsistent between the master publisher and the remote merge pull subscribers. (i.e., The subscribers have more recent data than the publisher.)

There are no error messages generated, and it's only for one article. The rest seem to update fine.

I am a complete noob when it comes to replication. How would I even start troubleshooting this? :S

Any assistance is appreciated. Thanks.

-D.http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=85908|||If it is a pull subscription, then does that not imply that the replication is one way? And then if the clients have more recent data it would indicate that data is being entered directly into the clients.|||Pootle_Flump,

Should I only be posting on one board?

Blindman,

The way I understand it is supposed to work is that data is entered on the remote subscribers, merged at the publisher, and then a snapshot pushes everything back down to the subscribers. The merges run throughout the day, and then snapshots are sent down at night, every couple of weeks.

I've checked the job logs on everything, and at the subscriber, I consistently see "No data needed to be merged." At the publisher, I do occasionally see an error like "The process could not bulk copy out of table 'contB83E8AA0AE6B4DBBBC147EAFA47D75F3'.", but the snapshot eventually succeeds, and the data matches more recently than that snapshot, with individual subscribers.

What to look at next? It's the "No data needed to be merged." that gets me...|||Pootle_Flump,

Should I only be posting on one board?Well - my preference is one at a time but I've got over that hang-up :) Some people consider it bad netiquette and will throw a wobbly about it. Some will avoid any cross-board posts.

The reason is simply that you can find yourself toiling away with a problem to find that others on another board have been privvy to info that would have helped you or,worse, you go down a blind alley that has already been covered elsewhere. Sorry to say as well that most users that cross post tend (IME) to have less invested in their threads and so are more likely to go AWOL too.

Anyway - I posted the link for our contributers to ensure that they can review what has gone on at SQLTeam before helping you out here. If it is resolved over there or there is a useful nugget of info then they can find out and not waste their time.
[/semi rant]

Ideally I would be grateful if you could keep the two threads in synch if any "break throughs" are made in either and also inform both if you manage to sort out your problem :) I think then everyone gets the best of both worlds.|||... and finally

I have not used merge replication so can't rather than won't help!|||Well - my preference is one at a time but I've got over that hang-up :) Some people consider it bad netiquette and will throw a wobbly about it. Some will avoid any cross-board posts.

...

Ideally I would be grateful if you could keep the two threads in synch if any "break throughs" are made in either and also inform both if you manage to sort out your problem :) I think then everyone gets the best of both worlds.

Gotcha. Makes total sense. I'll be more than happy to keep everyone on both boards in the loop.

Thanks.

-D.|||... and finally

I have not used merge replication so can't rather than won't help!

No sweat. Nobody is an expert on everything. ( I'm living proof of that! :D )

Thanks.

-D.|||I have one central publisher server and several remote merge pull boxes. On random remote servers, at random times, replication will fail. The data is inconsistent between the master publisher and the remote merge pull subscribers. (i.e., The subscribers have more recent data than the publisher.)

There are no error messages generated, and it's only for one article. The rest seem to update fine.

I am a complete noob when it comes to replication. How would I even start troubleshooting this? :S

Any assistance is appreciated. Thanks.

-D.

I'll give this a crack, only because we are in the process of rolling out merge replication to 60+ nodes (it's really ugly).

First:
- Which version of SQL Server (for publisher, distributor and subscriber(s))?
- What type of replication (snapshot, merge, or transactional)?
- What type of subscription (push or pull)?
- Are there horizontal filters on the articles?
- Are the publisher and the distributor on the same server?

I believe you are using Merge Replication (please correct me if I am wrong):

1. Look for conflicts (depending on version, right-click on the publication and select "View Conflicts")

- If there are conflicts, you will have to resolve each one individually

2. The way merge replication works (in a nutshell):

- There are three triggers on each article (table): insert, update, delete

- When DML changes data on the table, the appropriate trigger fires and places an entry into either msmerge_contents (insert, update) or msmerge_tombstone (delete). The data inserted into these tables includes the article nickname (an integer) and the rowguid of the updated row.

- When the merge agent next runs, it reads changes at the subscriber (ie, records in the appropriate msmerge_ table), then changes in the publisher. It tracks the history of changes using an integer value called generation.

If you are getting a message that no updates were made, then it means that no new entries were written (either at the publisher or the subscriber) into these msmerge_ tables.

OR POSSIBLY: if you are using horizontal filters on the articles, then it might mean that the merge agent has determined that the filter has excluded the particular subscriber from receiving updates.

I have tried merge replication (with dynamic horizontal filters) in both SQL 2000 and SQL 2005. I wholeheartedly recommend ditching SQL 2000 in favor of SQL 2005 (for both the publisher and the distributor). It's infinitely easier to set up publications and to manage replication (better reports, better conflict management, better alerts, just better).

You can also try this site for some of your questions:
http://www.replicationanswers.com/Default.asp

Be prepared for many long hours of reading to become comfortable with replication (esp Merge Replication). There are many quirks and features that may lead to less hair and less sleep.

Regards,

hmscott|||Greatly appreciated, hmscott.

- We are using both snapshot and merge replication. The snapshots appear to work fine. The merge is where the issue is.
- Both are pull subscriptions.
- There are no filters on any of the articles, either the snapshot or merge articles. They're different sets of articles.
- The publisher and distributor are indeed on the same server.

1. I'm not in the office, but I will look for conflicts when I get back in. I believe that conflict resolution was handled automatically in our configuration, if I recall correctly.

2. Let me see if I understand this correctly. When a change to a merge replicated table is made, a note is made in either the msmerge_contents table or the msmerge_tombstone table.

Since we're not using any filters on the articles, I'm wondering if the msmerge_contents or _tombstone tables are having issues, or maybe the triggers aren't working properly? Do either of those scenarios make sense?

Sadly, ditching 2k for 2k5 is not currently an option. Management prefers the "Even if it's broken, don't fix it! It may make it worse!" method of problem management.

I'll check the link out over the holiday. Thanks for the info.

And I'm bald already, so I should be good to go. :)

Thanks again for your help. I'll update again when I can find out more.

-D.|||I'll be in and out (mostly out) over the holiday.

I'm uncomfortable with the merge/snapshot thing. Maybe it's because I'm not understanding it correctly: is the same article involved in both merge and snapshot replication?

If so, I'm out of my league already; I didn't think that was possible.

But I'll look a bit further to see what I can find.

You might also consider having a look at sp_msmergedummyupdate (in SQL BOL). It might help "force" an update for replication.

Regards,

hmscott|||I'm uncomfortable with the merge/snapshot thing. Maybe it's because I'm not understanding it correctly: is the same article involved in both merge and snapshot repication?

If so, I'm out of my league already; I didn't think that was possible.

I don't think it is either. The article in question is only in the merge replication.

I'll definitely check out that sproc. Replication runs often enough during the day that it should be pretty easy to test.

Thanks again.

-D.|||Be prepared for many long hours of reading to become comfortable with replication (esp Merge Replication). There are many quirks and features that may lead to less hair and less sleep.

In this regard have you found a one-stop-shop for learning the minutiae of merge replication?
The best single resource I've found for transactional & snapshot replication has to be:
http://www.amazon.com/Guide-Server-Transactional-Snapshot-Replication/dp/0974973602/ref=sr_1_1/103-1393738-3011844|||In this regard have you found a one-stop-shop for learning the minutiae of merge replication?
The best single resource I've found for transactional & snapshot replication has to be:
http://www.amazon.com/Guide-Server-Transactional-Snapshot-Replication/dp/0974973602/ref=sr_1_1/103-1393738-3011844

You're right; I should have mentioned Mr. Cotter's book. As far as I am aware, Mr. Cotter is the expert on SQL replication.

Mostly, what I did was set up a Sandbox environment to test out various aspects of replication (mostly merge replication). I then repeated a number of tests and watched SQL Profiler (to see individual transactions) and the contents of various msmerge_ tables to see what transpired "under the hood". It was tedious but enlightening.

Regards,

hmscott|||From strange to stranger.

One of the developers on my team (my lead, actually) stated that the problem is fixed. In master..sysobjects, the replinfo column for that table object had been changed to 0 instead of 128, so the table was somehow not marked for replication. Nobody did this in EM or via script as far as we are aware, and the blame is currently being laid on a third party application. He marked that table for replication again, and it's working now.

Is that even possible? I thought ad-hoc updates to system tables weren't allowed. Unless the third-party app is running replication-altering sprocs, in which case, I'm scared.

I'm going to call this closed, for now. Thanks to everyone for their input. I learned a lot from this.

-D.|||From strange to stranger.

One of the developers on my team (my lead, actually) stated that the problem is fixed. In master..sysobjects, the replinfo column for that table object had been changed to 0 instead of 128, so the table was somehow not marked for replication. Nobody did this in EM or via script as far as we are aware, and the blame is currently being laid on a third party application. He marked that table for replication again, and it's working now.

Is that even possible? I thought ad-hoc updates to system tables weren't allowed. Unless the third-party app is running replication-altering sprocs, in which case, I'm scared.

I'm going to call this closed, for now. Thanks to everyone for their input. I learned a lot from this.

-D.

ad-hoc updates to system tables are allowed, but you have to run sp_configure 'allow updates' and set the value to 1. I don't generally recommend that you do this unless you know what values you are going to change and why.

You can try running profiler when the 3rd-party app is running to see what's going on under the hood. Warning: you may not like what you see.

Regards,

hmscott

No Data Needed To be Merged - But Only for INSERT ??

Hi All,
I'm receiving some strange behaviour from replication between SQL Server 2K/SQL CE.
Replicating UPDATE's to a table on my server works fine as viewed in the Replication
Monitor and the updated rows in the table.
However, if I replicate INSERTS, then Replication Monitor reports No Data Needed
To be Merged and the rows are not inserted in the table.
Has anyone come across this issue?
Cheers,
ciaran
Does your Table use Identity Values ?
If so, then you will need to set it to (Not For Replication).
|||Hi Gerry,
My table does use Identity Values, and it does have NOT FOR Replication set.
I also have Identity Ranges set.
Some more info. that has just come to light. Some rows DO insert, while other
rows do not. At one stage the SQL CE database that was on the devices was
physically deleted and re-initialised. Could it be that the old rows were left
lying around and that somehow this is preventing me from doing my inserts on
these rows? In which case what can I do? Delete rows from MSmerge_contents?
Thanks for the help !
|||By re-initialised do you mean you re-initialised the Subscription (i.e. under Replication Monitor / Publishers / right click on the publication and selected Reinitialise All Subscriptions ?)
Try running the option (again right click on the Publisher) and selet Validate all Subscriptions to see if
the subscriber is in sync with the publisher.
Check out BOL "Validating Replicatated Data" for more info on this.
sql

no .trn files

I have two sql servers, one is replicating to the other using log shipping.
The backup directory got deleted.
Now replication says it is working, but I don't know how because the .trn
files are not being generated.
What do I have to do to get that started again?
Scott EmickScott,
Repliction is not the same as log shipping. If you are replicating, the
process can continue without transaction logs, but your publisher db will
increase in size if it is not in SIMPLE recovery model and you are not
taking transaction log backups.
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"Scott Emick" <semick@.ham.phoenix-sys.com> wrote in message
news:OolQXwu$DHA.1212@.TK2MSFTNGP12.phx.gbl...
> I have two sql servers, one is replicating to the other using log
shipping.
> The backup directory got deleted.
> Now replication says it is working, but I don't know how because the .trn
> files are not being generated.
> What do I have to do to get that started again?
> Scott Emick
>|||I did flip all the db's from FULL to simple, and back again, but I
still get no .trn files. I was trying to read about backups and maint
plans yesterday, but I haven't gotten anywhere yet. Yes, the
replication is still working, and I am glad of that, but I would like
to get things back to the way they were.
Scott
"Ron Talmage" <rtalmage@.prospice.com> wrote in message news:<#qyZTf1$DHA.1844@.TK2MSFTNGP11.
phx.gbl>...
> Scott,
> Repliction is not the same as log shipping. If you are replicating, the
> process can continue without transaction logs, but your publisher db will
> increase in size if it is not in SIMPLE recovery model and you are not
> taking transaction log backups.
> Hope this helps,
> Ron
> --
> Ron Talmage
> SQL Server MVP
> "Scott Emick" <semick@.ham.phoenix-sys.com> wrote in message
> news:OolQXwu$DHA.1212@.TK2MSFTNGP12.phx.gbl...
> shipping.|||Also, restarted sql server agent and the maint plans...Apparently one was
hung and I did not know it...
Scott
"Scott Emick" <semick@.msn.com> wrote in message
news:a2794831.0403020315.1c3ad442@.posting.google.com...
> I did flip all the db's from FULL to simple, and back again, but I
> still get no .trn files. I was trying to read about backups and maint
> plans yesterday, but I haven't gotten anywhere yet. Yes, the
> replication is still working, and I am glad of that, but I would like
> to get things back to the way they were.
> Scott
> "Ron Talmage" <rtalmage@.prospice.com> wrote in message
news:<#qyZTf1$DHA.1844@.TK2MSFTNGP11.phx.gbl>...
will

no .trn files

I have two sql servers, one is replicating to the other using log shipping.
The backup directory got deleted.
Now replication says it is working, but I don't know how because the .trn
files are not being generated.
What do I have to do to get that started again?
Scott EmickScott,
Repliction is not the same as log shipping. If you are replicating, the
process can continue without transaction logs, but your publisher db will
increase in size if it is not in SIMPLE recovery model and you are not
taking transaction log backups.
Hope this helps,
Ron
--
Ron Talmage
SQL Server MVP
"Scott Emick" <semick@.ham.phoenix-sys.com> wrote in message
news:OolQXwu$DHA.1212@.TK2MSFTNGP12.phx.gbl...
> I have two sql servers, one is replicating to the other using log
shipping.
> The backup directory got deleted.
> Now replication says it is working, but I don't know how because the .trn
> files are not being generated.
> What do I have to do to get that started again?
> Scott Emick
>|||I did flip all the db's from FULL to simple, and back again, but I
still get no .trn files. I was trying to read about backups and maint
plans yesterday, but I haven't gotten anywhere yet. Yes, the
replication is still working, and I am glad of that, but I would like
to get things back to the way they were.
Scott
"Ron Talmage" <rtalmage@.prospice.com> wrote in message news:<#qyZTf1$DHA.1844@.TK2MSFTNGP11.phx.gbl>...
> Scott,
> Repliction is not the same as log shipping. If you are replicating, the
> process can continue without transaction logs, but your publisher db will
> increase in size if it is not in SIMPLE recovery model and you are not
> taking transaction log backups.
> Hope this helps,
> Ron
> --
> Ron Talmage
> SQL Server MVP
> "Scott Emick" <semick@.ham.phoenix-sys.com> wrote in message
> news:OolQXwu$DHA.1212@.TK2MSFTNGP12.phx.gbl...
> > I have two sql servers, one is replicating to the other using log
> shipping.
> >
> > The backup directory got deleted.
> >
> > Now replication says it is working, but I don't know how because the .trn
> > files are not being generated.
> >
> > What do I have to do to get that started again?
> >
> > Scott Emick
> >
> >|||Also, restarted sql server agent and the maint plans...Apparently one was
hung and I did not know it...
Scott
"Scott Emick" <semick@.msn.com> wrote in message
news:a2794831.0403020315.1c3ad442@.posting.google.com...
> I did flip all the db's from FULL to simple, and back again, but I
> still get no .trn files. I was trying to read about backups and maint
> plans yesterday, but I haven't gotten anywhere yet. Yes, the
> replication is still working, and I am glad of that, but I would like
> to get things back to the way they were.
> Scott
> "Ron Talmage" <rtalmage@.prospice.com> wrote in message
news:<#qyZTf1$DHA.1844@.TK2MSFTNGP11.phx.gbl>...
> > Scott,
> >
> > Repliction is not the same as log shipping. If you are replicating, the
> > process can continue without transaction logs, but your publisher db
will
> > increase in size if it is not in SIMPLE recovery model and you are not
> > taking transaction log backups.

Next Range Starting Value Too High

Hi, I've got a push merge replication set up between two sql servers on the
same domain. I have a table with about 1200 records in it. For some reason
when I publish the article and set the identity range values it chooses a
Next Range Starting Value of over 7000000 when there are only the 1200
records in the table (identity range of 100).
The table constraints at the publisher show the range of 1200 to 1300 but at
the subscriber it shows like 7000000 to 7000100.
Can I change it so that it forces it use a more reasonable number like 1300
to 1400?
When you setup the publication what did you specify as the values of
@.pub_identity_range and @.identity_range parameter to sp_addmergearticle?What
did you set as the identity range values in the UI? I believe you must have
set a very high value for the pub identity range and that is the reason you
are seeing these huge numbers on the subscriber. You can change the
pub_identity_range parameter by using sp_changemergearticle. However that
will not affect the max number that has already been allocated. Next time
you setup the publication use lower values for the @.pub_identity_range
parameter.
Thanks,
Jayanthi
"MBurns" <MBurns@.discussions.microsoft.com> wrote in message
news:577A372C-C296-4214-80D1-2D2BE5A25F97@.microsoft.com...
> Hi, I've got a push merge replication set up between two sql servers on
the
> same domain. I have a table with about 1200 records in it. For some reason
> when I publish the article and set the identity range values it chooses a
> Next Range Starting Value of over 7000000 when there are only the 1200
> records in the table (identity range of 100).
> The table constraints at the publisher show the range of 1200 to 1300 but
at
> the subscriber it shows like 7000000 to 7000100.
> Can I change it so that it forces it use a more reasonable number like
1300
> to 1400?

Newbie: which replication strategy should I use?

Hi all
My company is going to open new working centers on different locations of my region. One of the problems we are suffering is that at some locations, the network communications infrastructure is very very very poor. So, in that locations we work with low bandwidths, and connections usually break down.

Because of this, we are thinking in distributing our database. I have been doing some tests on replication, reading the docs, etc... But I am still not sure which replication strategy should we use, and how to organize our database tables to allow replication work properly.

Our offices are going to share some data (a product catalogue, for example) which could be updated an queried from any of the offices. But there is also data which is not going to be shared, as product stocks for each location.

We were thinking on using transactional peer-to-peer replication. But now we are having serious doubts about this since in a previous post (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1525643&SiteID=1) we were told we can't store non-shared data (stock) in the same table as the shared data (products) due to how database behaves when a publication is restarted. We know it would not be usual to republish, but we were thinking on crash recovery.

It would be fantastic if somebody could help us to decide what should we do to organize our database to allow the use of a proper replication scheme.

Thanks in advance,

Rubn D. M.

Considering your low bandwidths, have you looked at merge replication? It works best in a disconnected environment and over unreliable links as it has retry capabilities built in. you can also run agents at scheduled intervals. This would work provide you don't have low-latency requirement.

As far as your scenario goes where you want to replicate a table but not track changes in certain columns at both ends, this really won't work. In its simplest form you can do vertical partitioning at the publisher side, but that means any columns you choose to not replicate will not exist at the subscriber.

|||Hi Greg,
thank you very much for your help.

I thought transactional replication has also retry capabilities... So, what happens in a "transactional replication environment with updatable queued subscriptions" if the connection between publisher and subscriber is lost? Would it be needed to "restart" the subscription, or it will continue working correctly when connection is stablished again?

Thanks again ;-)

Regards

|||It does, but it's not as robust as merge replication, which is designed for the scenario you described.

NEWBIE: Replication Archive/deleting

Is it possible to run a query against a table and show records that have
been successfully replicated to the subscriber?
Thanks in advance
Tim
Timmeah,
what type of replication are you using? If it is transactional, you might be
interested in sp_browsereplcmds, and if it is merge, have a look at new! How
to...... Find a list of pending merge changes on
http://www.replicationanswers.com/Merge.asp.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Newbie: Merge Replication

I have setup merge replication and it appears to be working fine
multiple publishers to a single subscriber. with continuous push
subscription
If the subscribing SQL Server is unavailable for a period of time the
replication monitor shows an error
"could not connect to SERVERNAME"
Ok so fairly easy to understand.
Now when the subscribing server is available again it does not seem to
connect again. I can click the "start synchronizing" option from the
replication monitor, however I would have thought continuous updating would
reconnect when available.
If this is the case,
1. How can I make it connect/start sycnronising again sooner automatically,
without user invervention?
2. Am I able to call the start synchronising feature through commands so
that I can have a force update type feature through code.
Thanks in advance.
Cheers,
Tim
Timmeah,
you could schedule the merge agent to run once a minute rather than
continuously. Alternatively you could force the job steps to run in a loop.
To start the merge agent in TSQL you can use sp_start_job.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

newbie: how-to start a transactionnal replication ?

Hi,
I'm newbie on replication, so :
I own 2 MSSQL server 2000 servers :
- server A owns many populated databases (biggest is hundreds of Gb)
- server B is fresh installed and have no databases
I would replicate the server A over the server B so :
- I configured server A as publisher and local distributor,
- I created publications for transactional replications for databases I
wish to replicate on server A
- I created empty datadates on server B and I created subscriptions on
corresponding databases on server A
- I created a privilegied account on my AD domain for the transaction
coordinator service that can log on both servers
The problem is I should get an initial image snapshot for my databases on
server A, but I don't know how to create them...
thanks for any support ;)
Eric Belhomme
Eric,
as you have publications and subscriptions set up, you should now be in a
position to run the snapshot and distribution agents to initialise the
subscriber.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Are you getting any error/status messages when you run your distribution
agent?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Eric Belhomme" <{rico}+no/spam@.ricospirit.net> wrote in message
news:Xns973FA26E2C75Eericbelhommefreefr@.212.27.42. 134...
> Hi,
> I'm newbie on replication, so :
> I own 2 MSSQL server 2000 servers :
> - server A owns many populated databases (biggest is hundreds of Gb)
> - server B is fresh installed and have no databases
> I would replicate the server A over the server B so :
> - I configured server A as publisher and local distributor,
> - I created publications for transactional replications for databases I
> wish to replicate on server A
> - I created empty datadates on server B and I created subscriptions on
> corresponding databases on server A
> - I created a privilegied account on my AD domain for the transaction
> coordinator service that can log on both servers
> The problem is I should get an initial image snapshot for my databases on
> server A, but I don't know how to create them...
> thanks for any support ;)
> --
> Eric Belhomme
>
|||Look under your SQL Server Agent. There should be jobs for snapshot and
distribution, if everything setup correctly.
Now open the Replication Monitor and look to see if the Snapshot Agent has
run. If it has, then check to see if the distribution agent has applied
changes. If one or the other hasn't run, then right click on them and start
them.
Mike
Mentor
Solid Quality Learning
http://www.solidqualitylearning.com
"Eric Belhomme" <{rico}+no/spam@.ricospirit.net> wrote in message
news:Xns973FA26E2C75Eericbelhommefreefr@.212.27.42. 134...
> Hi,
> I'm newbie on replication, so :
> I own 2 MSSQL server 2000 servers :
> - server A owns many populated databases (biggest is hundreds of Gb)
> - server B is fresh installed and have no databases
> I would replicate the server A over the server B so :
> - I configured server A as publisher and local distributor,
> - I created publications for transactional replications for databases I
> wish to replicate on server A
> - I created empty datadates on server B and I created subscriptions on
> corresponding databases on server A
> - I created a privilegied account on my AD domain for the transaction
> coordinator service that can log on both servers
> The problem is I should get an initial image snapshot for my databases on
> server A, but I don't know how to create them...
> thanks for any support ;)
> --
> Eric Belhomme
>
|||"Michael Hotek" <mike@.solidqualitylearning.com> wrote in
news:#nJ5w#IEGHA.472@.TK2MSFTNGP12.phx.gbl:

> Now open the Replication Monitor and look to see if the Snapshot Agent
> has run. If it has, then check to see if the distribution agent has
> applied changes. If one or the other hasn't run, then right click on
> them and start them.
>
thanks all for your answers
It looks better now, but I'm still in trouble : on the "replication
monitor", I get red crosses on the "Editors" branch and on all my published
databases, except one.
But I can select replicated datas on my server B, and datas seems to be up
to date !
I don't know why I get these crosses, what they mean (I can't find any
errors and reports looks ok) and how to discard them...
Eric Belhomme
|||Eric,
if everything is running correctly, it may be that this error icon purely
relates to out-of-date info. The replication monitor gets its info from
tempdb.dbo.MSreplication_agent_status and running
sp_MSload_replication_status refreshes this table. As restarting the SQL
Server Service causes the tempdb to be recreated from the model database,
this also removes the problem.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)