Since NAV 2009 RTC, live has become .. let's say .. more challenging regarding "installations", isn't it ;-). There are loads of settings, parameters and configurations you have to get familiar with (Delegation, SPN, SQL Server, Active Directory, Kerberos fluff, ...) before you're even able to get it running. And then .. when you're completely in euphoria about being able to do so .. sometimes .. it's with the nose flat against the wall .. Because you notice that all the changes you're doing in Classic, are not reflected in RTC.

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:

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 sys.databases
where name not in ('master','model','msdb','tempdb')

OPEN
MyDatabases


FETCH NEXT FROM MyDatabases INTO @DBName


WHILE @@FETCH_STATUS = 0 BEGIN
SET @SQLString =
'DELETE FROM ['
+
@DBName + '].[dbo].[Object Tracking]'
print @SQLString


FETCH NEXT FROM MyDatabases INTO @DBName
END

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.