User-defined property in .msg persisted item not updating

Greets,

I have an AddIn that uses RDO to open emails that have been saved to .msg
files, as part of what is basically as a store-and-forward scheme to send
the emails up to a database. The .msg files are uploaded to server file
storage, and then a database record is built from various stock and
user-defined properties, plus a link to the .msg file on the server.

It is important that all items designated by the user make it into the
database, and equally important that no item is sent more than once.
(Actually, it doesn't matter if it's uploaded multiple times, but we don't
want any duplicate rows in the database.)

Unfortunately our end-users tend to be flighty little bastards that can't be
troubled to wait a couple of seconds to network i/o to complete. So
the algorithm must be prepared for failure at any stage, and capable of
resuming where it left off when a network connection becomes available
again.

To accomplish this, immediately after pushing to the database returns (with
the ID of the newly created row) I store that ID in the RDOMail object, in a
user-defined property, using HrSetOneProp, and then call SaveAs to overwrite
the same file. That way if pushing to database works but the next and final
stage fails, my code has a way to know this, as well as all the info it
needs to complete (which includes that ID.)

All of this works correctly for all of our end-users, except for one! On
her system it appears at first as though it works, HrSetOneProp returns 0
for success, and SaveAs does not throw an exception -- but the value of the
property (an integer) remains unchanged. (The property always gets created
in Outlook before the item is persisted to file.)

One thing I noticed about this machine is that it seems to take longer than
normal for files to be closed...

So does anyone have any idea why this might happen on an isolated system?
(I realize I'm reaching here, but had to ask. I also have no shortage of
possible alternative paradigms, so don't really need any more -- mostly just
want to know why this might fail.)


TIA,
Mark

If it's only one user my guess would be some other code running on their
machine that interacts with Outlook that's causing the problem.

Check for any addins, synch software and A-V addins.

Make sure to check for addins in the registry in both HKCU and HKLM to make
sure you spot all of them, in versions earlier than Outlook 2007 you don't
see addins registered in HKLM in the COM Add-Ins dialog.

I assume that everything else than that user prop is working on that
machine? The code isn't disabled and RDO is registered, etc.?

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Mark McGinty" <mmcginty.RemoveThis@spamfromyou.com> wrote in message
news:OIg5jjpKJHA.1308@TK2MSFTNGP02.phx.gbl...
> Greets,
>
> I have an AddIn that uses RDO to open emails that have been saved to .msg
> files, as part of what is basically as a store-and-forward scheme to send
> the emails up to a database. The .msg files are uploaded to server file
> storage, and then a database record is built from various stock and
> user-defined properties, plus a link to the .msg file on the server.
>
> It is important that all items designated by the user make it into the
> database, and equally important that no item is sent more than once.
> (Actually, it doesn't matter if it's uploaded multiple times, but we don't
> want any duplicate rows in the database.)
>
> Unfortunately our end-users tend to be flighty little bastards that can't
> be troubled to wait a couple of seconds to network i/o to complete.
> So the algorithm must be prepared for failure at any stage, and capable of
> resuming where it left off when a network connection becomes available
> again.
>
> To accomplish this, immediately after pushing to the database returns
> (with the ID of the newly created row) I store that ID in the RDOMail
> object, in a user-defined property, using HrSetOneProp, and then call
> SaveAs to overwrite the same file. That way if pushing to database works
> but the next and final stage fails, my code has a way to know this, as
> well as all the info it needs to complete (which includes that ID.)
>
> All of this works correctly for all of our end-users, except for one! On
> her system it appears at first as though it works, HrSetOneProp returns 0
> for success, and SaveAs does not throw an exception -- but the value of
> the property (an integer) remains unchanged. (The property always gets
> created in Outlook before the item is persisted to file.)
>
> One thing I noticed about this machine is that it seems to take longer
> than normal for files to be closed...
>
> So does anyone have any idea why this might happen on an isolated system?
> (I realize I'm reaching here, but had to ask. I also have no shortage of
> possible alternative paradigms, so don't really need any more -- mostly
> just want to know why this might fail.)
>
>
> TIA,
> Mark
>