Re: SaveChanges problem
- From: "Charles Wang[MSFT]" <changliw@xxxxxxxxxxxxx>
- Date: Fri, 15 Feb 2008 18:36:58 +0800
Hi Mark,
Currently we have not found any known issue regarding using OOM and MAPI
together.
Regarding the error code, you may refer to this article:
http://blogs.msdn.com/stephen_griffin/archive/2007/02/15/random-hresult-from-outlook-object-model.aspx
The error both times is MAPI_E_OBJECT_CHANGED. That means someone changed
the item in the backing DB while you had it opened. So your changes, if
committed, would clobber someone else¡¯s changes.
To track the root cause of this issue, we need to reproduce your issue.
Could you please mail me (changliw_at_microsoft_dot_com) a repro test
project or source code for further research?
Please feel free to let me know if you have any other questions or concerns.
Best regards,
Charles Wang
Microsoft Online Community Support
=====================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================
"Mark Smith" <sti@xxxxxxxxxxxxx> wrote in message
news:OSCppfcbIHA.4180@xxxxxxxxxxxxxxxxxxxxxxx
Yes, I do still get that error if I don't set any MAPI properties. In
fact, I removed all MAPI code (so, no get_MAPIOBJECT() call, etc.) and
still received the error.
Mark Smith
"Dmitry Streblechenko" <dmitry@xxxxxxxxxxx> wrote in message
news:exZKSHcbIHA.5400@xxxxxxxxxxxxxxxxxxxxxxx
Do you see an error if you *only* modify an OOM property and call Save?
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
"Mark Smith" <sti@xxxxxxxxxxxxx> wrote in message
news:ebqrJDbbIHA.3696@xxxxxxxxxxxxxxxxxxxxxxx
In this case I'm not setting an OOM user property, just a MAPI custom
property. As I said before, I did try doing only MailItem::Save instead
of both that and IMessage::SaveChanges. This did not eliminate the
problem. Though now that I'm resetting the subject property, as you
suggest, the error only occurs the first time I access the item again
rather than every subsequent time. So this is better, but I'm still
getting the error the first time after the message gets modified. Could
there be some kind of caching issue here?
Thank you,
Mark Smith
"Dmitry Streblechenko" <dmitry@xxxxxxxxxxx> wrote in message
news:edEKGWabIHA.5128@xxxxxxxxxxxxxxxxxxxxxxx
Why do you call IMessage::SaveChanges? MailItem.Save will do that, in
the worst case you will need to convince Outlook first that the item
has changed - resetting the Subject property will do fine. You won't
have to do even that if you are seeting a user property using th
MailItem.UserProperties collection
Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
"Mark Smith" <sti@xxxxxxxxxxxxx> wrote in message
news:u0mhGLabIHA.4880@xxxxxxxxxxxxxxxxxxxxxxx
Our program integrates with Outlook both via MAPI and OOM for a couple
different reasons. The primary of which is that we are using both
MAPI custom properties and OOM user defined fields (the user defined
fields code is not hit in this example). So I am unlikely to be able
to abandon either.
We are experiencing this problem in house. However, the person who
experiences has not been able to duplicate it reliably. I have not
been able to duplicate it normally, but I can when using Outlook Spy
to muck around with them item in question's properties.
Both computers that we've seen this on are using Oultook 2007 without
Exchange - one with SP1 and one without. I have not yet tried older
Outlooks.
This code is in C++.
The basic scenario is very simple:
[] I open up both a MAPI and OOM connection to Outlook
[] Using NameSpace::GetItemFromID(), I open up the item in question
directly by entry and store IDs, which returns an IDispatch
[] Then I attach a MailItem using CComQIPtr<Outlook::_MailItem>
[] Then I retrieve the MAPI object for the item in question using
get_MAPIOBJECT()
[] I set a custom property to the MAPI object using
IMapiProp::SetProps()
[] Then call IMessage::SaveChanges(KEEP_OPEN_READWRITE)
[] Then call MailItem::Save()
[] Then all objects go out of scope, thus cleaning them up (every
object is wrapped with a smart pointer (CComPtr or CComQIPtr, so it's
unlikely that I'm leaking any of them)
In some cases SaveChanges() returns 0x80040109 and Save() returns
0xf7a40109. I understand 0x80040109 to indicate that the object has
been changed and so the save will not happen. And I'm guessing that
0xf7a40109 is the same or similar.
This all executes very quickly - there is no UI in the middle or
anything else blocking execution to introduce a large window of
opportunity for the object to actually get changed out from under me.
As stated above, in order for me to reliably duplicate this I have to
use Outlook Spy to go in and make changes to the item in question
after this code executes once, but before the next time it is run on
the same item. If I try to make changes using Outlook's UI I haven't
been able to generate this error. Here's the crazy part: in order to
rule out a leak of an object on my part I've tried closing down my
program completely, restarting and attempting the same operation
again. The error still happens. And if I shut down Outlook at this
point, it does completely shut down on its own. Sometimes this is
within a second or two, other times it can take up to 20 seconds or
so. So it doesn't look like a leak of an object on my part. In order
to get this error to quit happening once it starts, I have to shut
Outlook down.
I haven't determined yet if the item is actually getting changed
between the time the object is opened and the save occurs (which, as
stated before, should be a very short time).
As a quick fix, I tried changing SaveChanges() to take FORCE_SAVE.
That does make the custom property get written to the item in
question, but then the next time I try to update this item I get an
access denied error.
I did also figure out that I don't have to call both SaveChanges() and
Save(). Calling just Save() is sufficient to save the properties to
the item, but doing so does not alleviate the problem.
I also tried using MailItem::Close(olSave) instead of Mailtem::Save().
This results in the error occuring every other time the procedure is
run. This is better, but still not a fix. What is different about
using MailItem::Close(olSave) instead of MailItem::Save() followed by
closing the object?
This situation really does sound like I'm leaking something, but I've
carefully checked over my code and can't find any leaks. Plus the
reasons described above lead me to conclude that this is not the
issue. The other possibility that I've considered is that Outlook may
be caching the object and then returning the same one back to me the
next time around, without the changes made by Outlook Spy.
So the questions are:
1) Am I doing something obviously wrong?
2) Is there some known problem with mixing OOM and MAPI?
3) If Outlook is caching objects, is there some way to guarantee I get
the latest copy of the object when I open it? I would think this
would be automatic, but something weird is happening here.
4) Is there some other possibility that I am missing?
I can provide code if that will help. I didn't initially because
there is a lot of it in several functions, so it will take a bit of
work to get it consolidated and trimmed down enough for a post.
Mark Smith
.
- Follow-Ups:
- Re: SaveChanges problem
- From: Mark Smith
- Re: SaveChanges problem
- References:
- SaveChanges problem
- From: Mark Smith
- Re: SaveChanges problem
- From: Dmitry Streblechenko
- Re: SaveChanges problem
- From: Mark Smith
- Re: SaveChanges problem
- From: Dmitry Streblechenko
- Re: SaveChanges problem
- From: Mark Smith
- SaveChanges problem
- Prev by Date: Re: PST file size modification
- Next by Date: Mail Relay between 2 exch2k3 servers in same domain
- Previous by thread: Re: SaveChanges problem
- Next by thread: Re: SaveChanges problem
- Index(es):
Relevant Pages
|
