Re: FindRow on Exchange
- From: "Dmitry Streblechenko" <dmitry@xxxxxxxxxxx>
- Date: Fri, 26 Oct 2007 10:11:26 -0700
1. PR_LONG_TERM_ENTRYID_FROM_TABLE (Exchange specific) will be the same as
the one returned by HrGetOneProp / IMessage::GetProps.
4. You can request PR_STORE_ENTRYID from the parent folder just before
retrieving the contents table. You can also use MAPIFolder.StoreID in OOM.
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
"Mark Smith" <sti@xxxxxxxxxxxxx> wrote in message
news:Ok2sQg9FIHA.4308@xxxxxxxxxxxxxxxxxxxxxxx
1) Ah, I wondered if it had something to do with short term entry ids, but
didn't know what to do about it. What is the value of
PR_LONG_TERM_ENTRYID_FROM_TABLE? Alternatively, I could open the item and
then request the entry id of it. That would get me the long term id,
right?
2) You are right. I forgot that you can't compare entry ids directly.
But my program wasn't doing that, I was just doing that by hand to check
what the program was doing.
3) I'm sorry, I must not have been clear here. The program doesn't know
the entry id, I went into Outlook using OutlookSpy to check what the entry
id should be for the item that gets found, which is how I knew (except for
item 2 above) that it wasn't right...
4) The reason I'm requesting the store id is that I'm stepping through
every store to look for this item. Since I'm re-opening the item using
OOM, I need the store id. I suppose that at some point I did have the
store id, so I could pass it down, saving some time at this level. Is
that what you are getting at? Unfortunately, I do need to use both MAPI
and OOM because I am using features of both that aren't available in the
other, specifically both named properties in MAPI and custom fields in
OOM.
Thanks,
Mark Smith
"Dmitry Streblechenko" <dmitry@xxxxxxxxxxx> wrote in message
news:%23atDrm3FIHA.5328@xxxxxxxxxxxxxxxxxxxxxxx
EX provider returns short term entry ids from the folder contents table.
You can still request teh long term entry id by specifying
PR_LONG_TERM_ENTRYID_FROM_TABLE property.
Secondly, you shouldd never directly compare entry ids that is what
IMAPISession::CompareEntryIDS for.
Thirdly, if you have the entry id, why search fro anything? Why not
directly open the message?
Fourthly, why request PR_STORE_ENTRYID? It will be the esaame for all
items in a folder and even in the parent store.
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
"Mark Smith" <sti@xxxxxxxxxxxxx> wrote in message
news:efEAXTzFIHA.1168@xxxxxxxxxxxxxxxxxxxxxxx
I've got a procedure where I've set a custom named property with a UUID
on a mail item and now I've got to go find it. So I step through every
folder in every data store and do a FindRow for my property. This has
worked every time for me so far with a non-Exchange Outlook. But when I
switch over to using Exchange the FindRow or QueryRows quits working the
way I expected. I am setting PR_ENTRYID and PR_STORE_ENTRYID plus my
custom property as the columns for the FindRow call. The FindRow and
QueryRows call both succeed when I am in the folder that the item lives.
And the property type of the row returned is not PT_ERROR. When I look
at the ENTRYID of the item that is returned, it is invalid. By invalid
I mean that it does not match the ENTRYID of the item that I am looking
for. And when I attempt to open up the ENTRYID that is returned, using
OutlookSpy, it says that there is no such item. In fact, the size of
the ENTRYID returned doesn't even match the size of the ENTRYID of the
item I am looking for.
Here's the relevant code (with some error handling removed for clarity:
_pFolder is an LPMAPIFOLDER which is the sent items folder in every case
that I have tested.
_pmIDPropTag is a const ULONG which is the property tag of my custom
property. I double checked that it is correct.
_pmID is a const CString which is the value for the custom property that
I am looking for. I also doubled checked that this value is correct.
hexFromBin is a pointer to the HexFromBin function out of the MAPI dll.
m_pNamespace is an Outlook::_NameSpace which was set up earlier.
bool foundItem = false;
CComPtr<IMAPITable> pTable;
if (SUCCEEDED(_pFolder->GetContentsTable(0, &pTable)) && (pTable.p !=
NULL)) {
// Get properties
enum { PMID, EID, STOREENTRYID, CNT };
SizedSPropTagArray(CNT, pmidPropTagArray) = { CNT, { _pmIDPropTag,
PR_ENTRYID, PR_STORE_ENTRYID } };
// Search for the item in this folder
pTable->SetColumns((LPSPropTagArray)&pmidPropTagArray, TBL_BATCH);
SRestriction restrict;
restrict.rt = RES_PROPERTY;
restrict.res.resProperty.relop = RELOP_EQ;
restrict.res.resProperty.ulPropTag = _pmIDPropTag;
SPropValue spv;
spv.ulPropTag = _pmIDPropTag;
spv.Value.lpszA = (LPTSTR)(LPCTSTR)_pmID;
restrict.res.resProperty.lpProp = &spv;
if (SUCCEEDED(pTable->FindRow(&restrict, BOOKMARK_BEGINNING, 0))) {
// Found it!
LPSRowSet pRow = NULL;
if (SUCCEEDED(pTable->QueryRows(1, 0, &pRow)) && (pRow != NULL))
{
if ((PROP_TYPE(pRow->aRow[0].lpProps[EID].ulPropTag) !=
PT_ERROR)
&& (pRow->aRow[0].lpProps[EID].Value.bin.lpb != NULL))
{
// Get entry id of item
std::auto_ptr<char> pEntryID(new char[(2 *
pRow->aRow[0].lpProps[EID].Value.bin.cb) + 1]);
hexFromBin(pRow->aRow[0].lpProps[EID].Value.bin.lpb,
pRow->aRow[0].lpProps[EID].Value.bin.cb,
pEntryID.get());
// Get entry id of store
std::auto_ptr<char> pStoreEntryID;
if
((PROP_TYPE(pRow->aRow[0].lpProps[STOREENTRYID].ulPropTag) != PT_ERROR)
&& (pRow->aRow[0].lpProps[STOREENTRYID].Value.bin.lpb !=
NULL))
{
pStoreEntryID = std::auto_ptr<char>(new char[(2 *
pRow->aRow[0].lpProps[STOREENTRYID].Value.bin.cb) + 1]);
hexFromBin(pRow->aRow[0].lpProps[STOREENTRYID].Value.bin.lpb,
pRow->aRow[0].lpProps[STOREENTRYID].Value.bin.cb, pStoreEntryID.get());
}
CComPtr<IDispatch> pDisp;
if
(SUCCEEDED(m_pNamespace->GetItemFromID(CComBSTR(pEntryID.get()),
(pStoreEntryID.get() == NULL) ? CComVariant() :
CComVariant(pStoreEntryID.get()), &pDisp)) && (pDisp.p != NULL)) {
...
The last call to find the item using OOM is failing. And yes, I am
properly cleaning things up at the end of the function.
I am expecting the ENTRYID's length to be 70, but the length being
returned is 40. And no, it is not just a truncated version of the
ENTRYID I am looking for.
Why is this happening? Is there a way to fix it?
Thank you for any assistance you can give,
Mark Smith
.
- Follow-Ups:
- Re: FindRow on Exchange
- From: Stephen Griffin [MSFT]
- Re: FindRow on Exchange
- References:
- FindRow on Exchange
- From: Mark Smith
- Re: FindRow on Exchange
- From: Dmitry Streblechenko
- Re: FindRow on Exchange
- From: Mark Smith
- FindRow on Exchange
- Prev by Date: Re: FindRow on Exchange
- Next by Date: MAPI/Outlook contacts encoding
- Previous by thread: Re: FindRow on Exchange
- Next by thread: Re: FindRow on Exchange
- Index(es):
Relevant Pages
|