Re: FindRow on Exchange
- From: "Mark Smith" <sti@xxxxxxxxxxxxx>
- Date: Fri, 26 Oct 2007 08:56:37 -0500
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: Dmitry Streblechenko
- Re: FindRow on Exchange
- References:
- FindRow on Exchange
- From: Mark Smith
- Re: FindRow on Exchange
- From: Dmitry Streblechenko
- FindRow on Exchange
- Prev by Date: Re: FindRow on Exchange
- Next by Date: Re: FindRow on Exchange
- Previous by thread: Re: FindRow on Exchange
- Next by thread: Re: FindRow on Exchange
- Index(es):
Relevant Pages
|
