Hey, waldo, I already know the solution of that problem ..
I bet you do. And you should, because there is already quite some info out there to fix it:
An MSDN article from Microsoft
A blog of Saurav Dhyani
Quite a similar blog from Peter Wibeck
Of course also something on the Dynamics Team blog
The one from the Team Blog is quite complete, and it explains how it works .. very interesting and unnecessary for me to blog again.
I have a feeling you have something to add..
Well, let's just say, I'm not sure if it was already mentioned by anyone somewhere .. . At least, when I was searching for a solution, the resources I found, were just not giving me any solution. Really, after applying all the stuff that was mentioned in the blogs, I still didn't find a solution: my listener was enabled, I didn't get any error in any log, polling in stead of the SQL Broker didn't work, ... . Nope .. my objects changes were not pushed (or pulled) to RTC.
So, what did I do..
Well, I started to watch the Object Tracking table, which is the core table for the Change Listener (for tracking changed objects). And when I saved a new version of the object, the ID in that tabel, wasn't the highest one in the table :-/ . It was something in between, and then it all makes sense, of course.. .
Is it a bug in classic, or did I do something wrong .. I don't know. But I do know this:
When removing all records from the "Object Tracking" table (I can't think of any problems it can cause), and restarting all NST's, fixed my problem.
I had to do this for about 50 databases, so I wrote some kind of script in SQL Server. May be it's useful for you:
DECLARE @DBName VARCHAR(50)DECLARE @SQLString VARCHAR(MAX)DECLARE MyDatabases CURSOR
FOR select name from
where name not
FROM MyDatabases INTO @DBNameWHILE
= 0 BEGIN
SET @SQLString = 'DELETE FROM [' + @DBName +
print @SQLString FETCH
FROM MyDatabases INTO @DBNameEND
This small script is will generate a script (yes indeed..) that you have to execute and which is going to empty the "Object Tracking"-table of all your databases. I could have extended this script to check if it's a NAV 2009 Database (or a NAV database nevertheless..). I did not do that, so you'll have to manage that yourself :-) (tip: you could check the "$ndo$dbproperty"-table where you'll find a field "databaseversionno" which should be greater or equal to "60000" (first version of NAV2009)). In our case, it just wasn't worth the effort.
My goal is to share my love and knowledge of Microsoft Dynamics software. If you want fluff-free stories about software with legs, you've come to the right place.
DynamicsTips.com is the place to get the latest news and technical tips on Microsoft Dynamics products, whether you're a developer or a user.