SqlSiteMapProvider - OnSiteMapChanged event never fires?

Question

I'm doing the Wicked Code implementation of SqlSiteMapProvider, except in VB.NET.

There's a few things with the code that are causing issues, and I don't understand how it is supposed to work the way it's written in the article. I've provided the code straight from the article provided below. I've pasted the code here for ease of viewing

First issue - the depedency is instantiated BEFORE (lines 134-137) the tree is created (151-160) - so as soon as you add the depedency to the http.cache (165-167), the OnSiteMapChanged event (242) fires immmediately - making the entire proccess run again - and this loops many times until finally something makes it stop. (i stepped through it and counted the code looping at least 20 times before I gave up on trying to guess when it hit last)

OK, so to fix this I just moved the code to the create the dependency to AFTER the tree is built, right before inserting to http.cache (so HasChanged property is false when adding to http.cache, and you don't get stuck in this psuedo-ifinite-loop).

I still have a problem though - every time a page loads, the BuildSiteMap() hits and line 121 checks if _root is not null - it seems it is never null after it is first built... this is good because I don't want to hit the DB each time. Now, I insert a record into the table... the OnSiteMapChanged event never fires. As I browse pages on the app, the sitemap does not reflect the newly inserted record - stepping through the code, I see that the check at line 121 is still causing the function to short circuit... The sitemap will only refresh if i re-start Visual Studio, which causes the private _root field to become null again, and re-builds the sitemap, reflecting the new changes.. (refreshing the browser or starting new browser instances does not work)...

EDIT: THE ISSUE STEMMED FROM A SILLY 'SET NOCOUNT ON' LINE IN THE TOP OF MY STORED PROC. APPARENTLY THIS BREAKS THE QUERY NOTIFICATION. It seems that this statement is seen as a result set and that the second, actual query statement invalidates the result set resulting in a notification. This was very hard to find and nowhere in the MSDN documentation until I added the comment. Hope this saves someone else the miser I went through!

Answer 1

THE ISSUE STEMMED FROM A SILLY 'SET NOCOUNT ON' LINE IN THE TOP OF MY STORED PROC. APPARENTLY THIS BREAKS THE QUERY NOTIFICATION. It seems that this statement is seen as a result set and that the second, actual query statement invalidates the result set resulting in a notification. This was very hard to find and nowhere in the MSDN documentation until I added the comment. Hope this saves someone else the miser I went through!