Under certain situations I want to test for the existence of certain messages
in the store for which I have an entry ID (so I can iterate through a list,
and remove anything that doesn't exist anymore.) I tried the following:

if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) != MAPI_E_UNKNOWN_ENTRYID)
{
// This code should only execute if the ID is not valid...right?
}

Notice that I compare the id against itself. I would expect this to always
return S_OK unless the id was not valid. This seemed to work on my computer,
however, in testing we found at least one computer where CompareEntryIDs was
returning MAPI_E_UNKNOWN_ENTRYID around 50% of the time, even when id
contained a valid entryid. The computer in question was a tablet PC running
XP SP2 and Outlook 2003 w/ Exchange Server 2003.

I don't need a workaround, I have another solution in place for now. My
question is WHY this function would fail so badly on perhaps the easiest
possible case. I need to know, since I obviously have to use CompareEntryIDs
for more normal things. Any ideas?

Because it does not know which provider is supposed to handle that
particular entry id?
Does the entry id come from a store that you have never touched in teh
current MAPI session?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Count Infinity" wrote in message
...
Under certain situations I want to test for the existence of certain
messages
in the store for which I have an entry ID (so I can iterate through a
list,
and remove anything that doesn't exist anymore.) I tried the following:

if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) != MAPI_E_UNKNOWN_ENTRYID)
{
// This code should only execute if the ID is not valid...right?
}

Notice that I compare the id against itself. I would expect this to always
return S_OK unless the id was not valid. This seemed to work on my
computer,
however, in testing we found at least one computer where CompareEntryIDs
was
returning MAPI_E_UNKNOWN_ENTRYID around 50% of the time, even when id
contained a valid entryid. The computer in question was a tablet PC
running
XP SP2 and Outlook 2003 w/ Exchange Server 2003.

I don't need a workaround, I have another solution in place for now. My
question is WHY this function would fail so badly on perhaps the easiest
possible case. I need to know, since I obviously have to use
CompareEntryIDs
for more normal things. Any ideas?

Actually no. The entry id in every case is for a message that I already
opened at one point, read, and used information from to populate a list. The
software operates across several stores, so the stores are all kept open.
Therefore, in the current session, the store is open, and has been used to
open this particular message at least once.

Further testing reveals that the following also fails:
CMAPIMessage msg; // internal class to encapsulate this
if (!msg.Open(&mapi, id, 0))
{
// open failed
}
else if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) == MAPI_E_UNKNOWN_ENTRYID)
{
// In theory the entry id should not exist if we get here...
}
msg.Close();


"Dmitry Streblechenko" wrote:

Because it does not know which provider is supposed to handle that
particular entry id?
Does the entry id come from a store that you have never touched in teh
current MAPI session?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Count Infinity" wrote in message
...
Under certain situations I want to test for the existence of certain
messages
in the store for which I have an entry ID (so I can iterate through a
list,
and remove anything that doesn't exist anymore.) I tried the following:

if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) != MAPI_E_UNKNOWN_ENTRYID)
{
// This code should only execute if the ID is not valid...right?
}

Notice that I compare the id against itself. I would expect this to always
return S_OK unless the id was not valid. This seemed to work on my
computer,
however, in testing we found at least one computer where CompareEntryIDs
was
returning MAPI_E_UNKNOWN_ENTRYID around 50% of the time, even when id
contained a valid entryid. The computer in question was a tablet PC
running
XP SP2 and Outlook 2003 w/ Exchange Server 2003.

I don't need a workaround, I have another solution in place for now. My
question is WHY this function would fail so badly on perhaps the easiest
possible case. I need to know, since I obviously have to use
CompareEntryIDs
for more normal things. Any ideas?

I can only suspect memory corruption of some kind. Try to output the valeu
of the entry id.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Count Infinity" wrote in message
...
Actually no. The entry id in every case is for a message that I already
opened at one point, read, and used information from to populate a list.
The
software operates across several stores, so the stores are all kept open.
Therefore, in the current session, the store is open, and has been used to
open this particular message at least once.

Further testing reveals that the following also fails:
CMAPIMessage msg; // internal class to encapsulate this
if (!msg.Open(&mapi, id, 0))
{
// open failed
}
else if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) == MAPI_E_UNKNOWN_ENTRYID)
{
// In theory the entry id should not exist if we get here...
}
msg.Close();


"Dmitry Streblechenko" wrote:

Because it does not know which provider is supposed to handle that
particular entry id?
Does the entry id come from a store that you have never touched in teh
current MAPI session?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Count Infinity" wrote in
message
...
Under certain situations I want to test for the existence of certain
messages
in the store for which I have an entry ID (so I can iterate through a
list,
and remove anything that doesn't exist anymore.) I tried the following:

if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) != MAPI_E_UNKNOWN_ENTRYID)
{
// This code should only execute if the ID is not valid...right?
}

Notice that I compare the id against itself. I would expect this to
always
return S_OK unless the id was not valid. This seemed to work on my
computer,
however, in testing we found at least one computer where
CompareEntryIDs
was
returning MAPI_E_UNKNOWN_ENTRYID around 50% of the time, even when id
contained a valid entryid. The computer in question was a tablet PC
running
XP SP2 and Outlook 2003 w/ Exchange Server 2003.

I don't need a workaround, I have another solution in place for now. My
question is WHY this function would fail so badly on perhaps the
easiest
possible case. I need to know, since I obviously have to use
CompareEntryIDs
for more normal things. Any ideas?

Well, the fact that the open accurately retrieves the record tends to speak
against a corrupt id theory.

I do feel better, however, knowing that this confuses the leading expert in
all things MAPI, not just me.

"Dmitry Streblechenko" wrote:

I can only suspect memory corruption of some kind. Try to output the valeu
of the entry id.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Count Infinity" wrote in message
...
Actually no. The entry id in every case is for a message that I already
opened at one point, read, and used information from to populate a list.
The
software operates across several stores, so the stores are all kept open.
Therefore, in the current session, the store is open, and has been used to
open this particular message at least once.

Further testing reveals that the following also fails:
CMAPIMessage msg; // internal class to encapsulate this
if (!msg.Open(&mapi, id, 0))
{
// open failed
}
else if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) == MAPI_E_UNKNOWN_ENTRYID)
{
// In theory the entry id should not exist if we get here...
}
msg.Close();


"Dmitry Streblechenko" wrote:

Because it does not know which provider is supposed to handle that
particular entry id?
Does the entry id come from a store that you have never touched in teh
current MAPI session?

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Count Infinity" wrote in
message
...
Under certain situations I want to test for the existence of certain
messages
in the store for which I have an entry ID (so I can iterate through a
list,
and remove anything that doesn't exist anymore.) I tried the following:

if (m_pSession-CompareEntryIDs(id.cb, (LPENTRYID)id.lpb, id.cb,
(LPENTRYID)id.lpb, 0, &ul) != MAPI_E_UNKNOWN_ENTRYID)
{
// This code should only execute if the ID is not valid...right?
}

Notice that I compare the id against itself. I would expect this to
always
return S_OK unless the id was not valid. This seemed to work on my
computer,
however, in testing we found at least one computer where
CompareEntryIDs
was
returning MAPI_E_UNKNOWN_ENTRYID around 50% of the time, even when id
contained a valid entryid. The computer in question was a tablet PC
running
XP SP2 and Outlook 2003 w/ Exchange Server 2003.

I don't need a workaround, I have another solution in place for now. My
question is WHY this function would fail so badly on perhaps the
easiest
possible case. I need to know, since I obviously have to use
CompareEntryIDs
for more normal things. Any ideas?