--
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
"A. Robinson" <ARob...@discussions.microsoft.com> wrote in message
news:3E0E8064-B3AB-4350...@microsoft.com...
> This is the message that has been displaying from my distribution agent
for
> the last two hours!! Funny thing is, according to the log reader, there
are
> no replicated transactions available. Also, when I run sp_repltrans, i get
NO
> rows back.....
>
> What is going on?!?!
>
> Any help would be appreciated...
>
> Thanks!!
I'm unfamiliar with that particular option...and I can't find it in BOL.
Could you possibly shed some light?
Thanks!
Just realized I DID use that concurrent snapshot option. Is thyat the option
that says don't lock tables while doing snapshot? If so, I sure did use that
option...
So why does that option add so much overhead to the snapshot generation? The
database I snapshot-ed didn't have any users on it at all....
Sorry about the misinformation...
"A. Robinson" <ARob...@discussions.microsoft.com> wrote in message
news:C19B8A84-E1C1-465E...@microsoft.com...
Recently I've solved this problem by recreating the primary key at the
subscriber manually. The snapshot kept saying that the primary key had been
created but when I checked it was not. Right after I created it, the
syncronization process came back to normal, applying all the undistributed
commands finally. I then checked the properties of the publication for the
table being replicated (just one in this case) and saw that the "recreate
clustered indexes" option was marked as 'true'. However, I saw no script for
recreating this object in the snapshot folder. A bug perhaps? I created a
script and put it to execute automatically every time SQL Server generates a
new snapshot. Of course that all that discovery and solution came after many
hours of suffering trying to identify the problem itself.