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

"Mark J. McGinty" wrote in message
...

"Rog" wrote in message
...
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

Rog wrote:
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

Dmitry Streblechenko wrote:
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" wrote in message
...
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 wrote:
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" wrote in message
...
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 wrote:
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" wrote in message
...
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 wrote:
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" wrote in message
...
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