Fast search in Outlook

[Vladimir Chtchetkine]

I need to be able to quickly find an item in Outlook (within a given folder
branch) based on a certain unique property value (essentially, a GUID
string). I don't mind going down to the MAPI level (I'm there anyways I
just need to be able to open an item based on that GUID as quick as
possible. Maintaining a map of GUID->EntryID is not that attractive to me
because it creates additional headaches monitoring for item moving to
another folder (and I still want to be able to find it in that new folder
too). Since the actual store (in my case a local .pst file) seems to be a
DB-backed "thing" is there any form of queries (other than EntryID) or
something like that available?

Sorry if the question is too vague but that's the best I can do

 

[Ken Slovak - [MVP - Outlook]]

You could use a MAPITable and restriction or filter. I do that for maximum
speed using Redemption.

You would set up a condition for your GUID using the property tag for your
user defined property and a RES_PROPERTY filter and then retrieve the
EntryID. Very quick.

 

[Vladimir Chtchetkine]

Thanks, Ken!



Yep, I tried that (you're talking about MAPI table's FindRow method,
right?)... And I have mixed feelings Although it's not that bad
performance-wise but it's still far away from what I would like it to be...
I'm dealing with pretty massive amount of items (tens of thousands would be
an average) and performing a linear search on that doesn't seem right.
Unfortunately, it seems that there is no silver bullet for that. The worst
thing is that I couldn't find a reliable (yet fairly simple) way to maintain
my map in memory because there is no way (to the best of my knowledge) how
you can monitor items being moved from one folder to another. The only real
possibility is to watch for "folder change" events and then waltz with their
items lists. One-two-three, one-two three. Brrrrr..

 

[Ken Slovak - [MVP - Outlook]]

FindRow, yes. However if there's a filter on the table you would only return
rows that meet the filter so even with thousands of items in a folder it
still would only return those that matched. So a small subset of the
thousands would be returned.

Yeah, the real problem has always been that ItemRemove doesn't tell you what
was removed and BeforeDelete only fires in open Inspectors. We have no
useful way of tracking deletions without using workarounds. <sigh> One of
the many tribulations of being an Outlook developer. </sigh>