Why Outlook Won't Show Your Messages
We've gotten a rash of cases where message store developers complain that their store worked "perfectly fine" against Outlook 2003, but is broken now with Outlook 2007. The common symptom with all of them is that at some point, Outlook stops rendering any items in a folder. Maybe some times you can click on a folder and items will show up, but at some point, you get nothing. Once you get nothing, you continue to get nothing. Clicking on another folder and clicking back may or may not fix the problem. For a while. Until it comes back. And like Ah-nuld, it always comes back.
This was a fun issue to debug. What I found is that Outlook 2007 is a lot less tolerant of "funny business" from a contents table than earlier versions of Outlook were. When it detects "funny business", it gives up on the table and flatly refuses to render it. This is a defense mechanism designed to keep Outlook from crashing.
So what is the "funny business" Outlook is detecting? Basically it doesn't like store providers that lie. Let's look at some basic operations needed to render a folder:
In SetColumns, Outlook passes a list of property tags it would like the provider to use for columns in the table. This isn't a suggestion. Outlook expects (as it should) that if it asked for 30 columns and SetColumns doesn't return an error, then the table will have 30 columns. Every row returned by QueryRows will have exactly 30 columns, and they'll be the same exact columns Outlook requested, in the same exact order. Any deviation sends you to the penalty box.
Outlook 2003, has the same expectations. But it would 'fail' on a row by row basis. If you handed Outlook 2003 three rows, one with every column requested in SetColumns, one with an extra column, and one with the right number of columns, but in a different order or with some different properties substituted, it would render the one "correct" row. The two others would silently fail. Except in the few cases where Outlook didn't quite spot the inconsistency, trusted the row was what it asked for, and crashed when it wasn't. Or didn't crash, but just had general odd behavior.
As you can see, this made it very hard to track down when a provider was being naughty. So Outlook 2007 took the defense one step further. As soon as it discovers the inconsistency between the columns it asked for and what it got, it decides the whole table is messed up (which it is) and refuses to talk to it again. This is why switching away and back sometimes works - because Outlook reloads the table, and as long as it doesn't lie Outlook will continue to work with it.
So, if you've got a store provider and you're facing this issue with Outlook not rendering your tables, pay close attention to the columns Outlook asked for and what you handed back. You may just be shooting yourself in the foot.