ItemChange and Exchange synchronization

[Rog]

I am using the ItemChange event in my C# code to capture when an item is
saved and then do something with it. The problem is I do not want to
do this action when Exchange is syncing. Is there anyway to determine
when exchange is doing its auto-sync so i can not run the code?
Thanks so much

 

[Dmitry Streblechenko]

No, the cached Exchange provider provides no notification.
Why wouldn't you want to run your code? Does it matter whether a change
occured because the current user modified an item or because it got modified
on a different machine and the Exchange provider received the notification
and updated the local copy?

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

 

[Rog]

Thanks Dmitry for your response. Well basically once a user does a save
I capture the ItemChange event and log the item that was change to a
local db. Then when they click a button I try to sync to the contact up
to a server based on the values from the local db file. In addition to
syncing from outlok I also sync down from the server to outlook and save
the item. During the syncing I set a flag so anything that is saved
will not trigged the ItemChange event, but once my sync process is
complete, I change the flag to capture the next time someone modifies a
contact. So the problem is about 30 secs after my sync process is
complete and the flag is reset, Outlook syncs with exchange which causes
the ItemChange event to fire and me to resave the item as modified in my
local b file which triggers the whole process over again when nothing
has really changed.
Does that make sense?

 

[Rog]

Thanks Dmitry for your response. Well basically once a user does a save
I capture the ItemChange event and log the item that was change to a
local db. Then when they click a button I try to sync to the contact up
to a server based on the values from the local db file. In addition to
syncing from outlok I also sync down from the server to outlook and save
the item. During the syncing I set a flag so anything that is saved
will not trigged the ItemChange event, but once my sync process is
complete, I change the flag to capture the next time someone modifies a
contact. So the problem is about 30 secs after my sync process is
complete and the flag is reset, Outlook syncs with exchange which causes
the ItemChange event to fire and me to resave the item as modified in my
local b file which triggers the whole process over again when nothing
has really changed.
Does that make sense?

 

[Rog]

Thanks Dmitry for your response. Well basically once a user does a save
I capture the ItemChange event and log the item that was change to a
local db. Then when they click a button I try to sync to the contact up
to a server based on the values from the local db file. In addition to
syncing from outlok I also sync down from the server to outlook and save
the item. During the syncing I set a flag so anything that is saved
will not trigged the ItemChange event, but once my sync process is
complete, I change the flag to capture the next time someone modifies a
contact. So the problem is about 30 secs after my sync process is
complete and the flag is reset, Outlook syncs with exchange which causes
the ItemChange event to fire and me to resave the item as modified in my
local b file which triggers the whole process over again when nothing
has really changed.
Does that make sense?

 

[Rog]

Thanks Dmitry for your response. Well basically once a user does a save
I capture the ItemChange event and log the item that was change to a
local db. Then when they click a button I try to sync to the contact up
to a server based on the values from the local db file. In addition to
syncing from outlok I also sync down from the server to outlook and save
the item. During the syncing I set a flag so anything that is saved
will not trigged the ItemChange event, but once my sync process is
complete, I change the flag to capture the next time someone modifies a
contact. So the problem is about 30 secs after my sync process is
complete and the flag is reset, Outlook syncs with exchange which causes
the ItemChange event to fire and me to resave the item as modified in my
local b file which triggers the whole process over again when nothing
has really changed.
Does that make sense?

 

[Dmitry Streblechenko]

I sam confused - why would ItemChange fire if you did not change it again?
Or if a new change did not come from the EX server?

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

 

[Rog]

Thanks Dmitry, so what happens is I save the contact in the code,
ItemChange fires, of course, but b/c my flag is set, I do not resave it
again to my local db. But then it seems b/c I just saved the Contact
about 30 seconds later the ItemChange event fires b/c it seems that
Exchange is doing the synchronization.
Does this make sense?

 

[Dmitry Streblechenko]

Hmmm.. I do not see that secondd event in the cached mode...
I guess you could store a hash made out of the values that you care about
(e.g .Email1Address + FileAs + ...) - if the hash is still the same, do
nothing.

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

 

[Rog]

Good suggestion Dmitry, so does that mean there is no way to catch this
exchange sync event programmatically within Outlook? If I triggered the
exchange sync to happen so that I could control my flag and not save to
my local db file, would I be able to prevent it from happening at
another time besides when the user saves the item?
Rog

 

[Dmitry Streblechenko]

No, you wouldn't be able to know what exactly caused that event to fire.

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

 

[Rog]

Thanks Dmitry for your help, I figured I would post back what I ended up
implementing. For whatever reason i had forgotten, code bloat
possibly, that I had kept a lastsyncdate variable so in the ItemChange
handler I check the lastmodificationTime of the outlook object against
the last sync date, if the modtime is greater I save to my db file
otherwise I do not nothing.
Thanks,
Rog

 

[Rog]

I think I spoke to soon on this one. if the exchange server time is off
or it is trying to sync objects down from exchange the
lastmodificationtime will be greater that the local sync date time.
back to square one. Anyone have any other ideas?
Rog

 

[Dmitry Streblechenko]

Do you read the LastModificationTime property from the item itself?

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

 

[Mark J. McGinty]

I think I spoke to soon on this one. if the exchange server time is off or
it is trying to sync objects down from exchange the lastmodificationtime
will be greater that the local sync date time.
back to square one. Anyone have any other ideas?

Basically what you must do is make sure you call the Item.Save method *only*
when you have actually changed something significant in the item. Calling
Item.Save writes the item unconditionally, which resets LastMod; any time
you do this, Exchange will come right along behind you, sync the item, and
save it again.

In other words, when Exchange is the provider, there is already one thing
running that will unconditionally re-write an item once for every time
something else writes that same item [since it was last synced by Exchange.]
If your code does this *too*, it sets-up an endless i/o cycle.

To manage this I check the Item.Saved property before calling the Item.Save
method; I only call Item.Save if Item.Saved = False... but there are at
least a couple of hitches...

One is, if you are working with AppointmentItem or TaskItem, and you update
a recurrence pattern, Item.Saved will not always reflect this, though you
must call Save to keep the changes to recurrence.

Another is that any Item property assignment will cause Saved to return
false, even if the value is unchanged by the assignment. e,g.,

Dim tmp
tmp = Item.SomeProperty
Item.SomeProperty = tmp
' the following condition will evaluate as True
If (Item.Saved = False) Then [..]

So for every Item property I assign, I first check for inequality... but
again there are caveats...

Merely checking for exact programmatic equality will leave you in almost the
same cycle, for instance, Exchange likes a trailing blank line on the Body
property, and it likes to format phone numbers. To me these levels of
change aren't worth the i/o it would take to push them to SQL Server, so my
comparison routines are written to ignore them accordingly.

Also, dates can pose a special problem, depending on where you store them
outside of OL/Exchange, due to low-level differences in the way they are
stored. e.g.,

' assume rs is an ADODB.Recordset connected to SQL Server
rs!LastModificationTime = Item.LastModificationTime
rs.Update
rs.Requery ' simulate retrieving the record at a later time
' the following condition may *not* evaluate as True
' assume the item has not been written since its LastMod was stored
If (rs!LastModificationTime = Item.LastModificationTime) Then [..]

Long story short, though you can't determine which module caused ItemChange
to fire, you can expect -- indeed you must expect -- that Exchange will
routinely do so without significantly changing the item's content. As such,
IMHO, it's more constructive to evaluate what has been written, rather than
what was responsible for writing it.


-Mark

 

[Dmitry Streblechenko]

As a rule of thumb, one should never us "=" when comparing datetime
properties due to the round-off errors - always compare the absolute value
of a difference between two values. E.g. if the absolute value of a
difference is less than 1 millisecond, the values are the same for all
practical purposes.

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

I think I spoke to soon on this one. if the exchange server time is off or
it is trying to sync objects down from exchange the lastmodificationtime
will be greater that the local sync date time.
back to square one. Anyone have any other ideas?

Basically what you must do is make sure you call the Item.Save method
*only* when you have actually changed something significant in the item.
Calling Item.Save writes the item unconditionally, which resets LastMod;
any time you do this, Exchange will come right along behind you, sync the
item, and save it again.

In other words, when Exchange is the provider, there is already one thing
running that will unconditionally re-write an item once for every time
something else writes that same item [since it was last synced by
Exchange.] If your code does this *too*, it sets-up an endless i/o cycle.

To manage this I check the Item.Saved property before calling the
Item.Save method; I only call Item.Save if Item.Saved = False... but there
are at least a couple of hitches...

One is, if you are working with AppointmentItem or TaskItem, and you
update a recurrence pattern, Item.Saved will not always reflect this,
though you must call Save to keep the changes to recurrence.

Another is that any Item property assignment will cause Saved to return
false, even if the value is unchanged by the assignment. e,g.,

Dim tmp
tmp = Item.SomeProperty
Item.SomeProperty = tmp
' the following condition will evaluate as True
If (Item.Saved = False) Then [..]

So for every Item property I assign, I first check for inequality... but
again there are caveats...

Merely checking for exact programmatic equality will leave you in almost
the same cycle, for instance, Exchange likes a trailing blank line on the
Body property, and it likes to format phone numbers. To me these levels
of change aren't worth the i/o it would take to push them to SQL Server,
so my comparison routines are written to ignore them accordingly.

Also, dates can pose a special problem, depending on where you store them
outside of OL/Exchange, due to low-level differences in the way they are
stored. e.g.,

' assume rs is an ADODB.Recordset connected to SQL Server
rs!LastModificationTime = Item.LastModificationTime
rs.Update
rs.Requery ' simulate retrieving the record at a later time
' the following condition may *not* evaluate as True
' assume the item has not been written since its LastMod was stored
If (rs!LastModificationTime = Item.LastModificationTime) Then [..]

Long story short, though you can't determine which module caused
ItemChange to fire, you can expect -- indeed you must expect -- that
Exchange will routinely do so without significantly changing the item's
content. As such, IMHO, it's more constructive to evaluate what has been
written, rather than what was responsible for writing it.


-Mark

Rog