Community Discussions and Support
Outlook UID Error

I've not been able to recreate this.

As soon as it happens, I'll post details.

David - any plans with IMAP filtering ?? 

<p>I've not been able to recreate this.</p><p>As soon as it happens, I'll post details.</p><p>David - any plans with IMAP filtering ?? </p>

Today we started to get a couple of UID errors in Outlook 2003.

2 users connecting to the same IMAP account. Mercury v4.62.

Error:

The UID of a message changed unexpectedly. This typically indicates a server bug. Your program may not function properly after this.

MsqSeqNum 68: Previuos UIDL 141, New UID: 68

 

Any ideas ? Thanks
 

<p>Today we started to get a couple of UID errors in Outlook 2003.</p><p>2 users connecting to the same IMAP account. Mercury v4.62.</p><p>Error:</p><p>The UID of a message changed unexpectedly. This typically indicates a server bug. Your program may not function properly after this.</p><p>MsqSeqNum 68: Previuos UIDL 141, New UID: 68</p><p> </p><p>Any ideas ? Thanks  </p>

IMAP is an incredibly dense, technical protocol, and is very, very difficult to debug. The only way I can even *hope* to do anything about this for you is if you can generate a session transcript showing the full set of commands exchanged between Mercury and the connected client leading up to the error; I really don't know anything much about Outlook - it might or might not be able to generate this type of transcript... But Mercury certainly can: if you are able to generate this error on demand, please turn on session logging in the MercuryI configuration dialog, produce the error, then send me the session log (remember to turn session logging off again afterwards - it eats disk space at an alarming rate over time).

Once I see a session log, I should be able to give you a better idea of what's going on, and what might be done to fix it.

Cheers!

-- David --

IMAP is an incredibly dense, technical protocol, and is very, very difficult to debug. The only way I can even *hope* to do anything about this for you is if you can generate a session transcript showing the full set of commands exchanged between Mercury and the connected client leading up to the error; I really don't know anything much about Outlook - it might or might not be able to generate this type of transcript... But Mercury certainly can: if you are able to generate this error on demand, please turn on session logging in the MercuryI configuration dialog, produce the error, then send me the session log (remember to turn session logging off again afterwards - it eats disk space at an alarming rate over time). Once I see a session log, I should be able to give you a better idea of what's going on, and what might be done to fix it. Cheers! -- David --

A session log will not yield anything. You need to look at a backup of your maildrop. Compare the two _INBOX_.PNM with each other. Contents should look like:

V 1104942610

N 1152

U 1150 Y240ICPZ.CNM

U 1151 Y1BIUPGG.CNM

the N 1152, states that next UID should be, but for your message U 141, you'd have the same Y####.CNM file as for the U 68.
A session log will not yield anything. You need to look at a backup of your maildrop. Compare the two _INBOX_.PNM with each other. Contents should look like: <PRE>V 1104942610 N 1152 U 1150 Y240ICPZ.CNM U 1151 Y1BIUPGG.CNM </PRE>the N 1152, states that next UID should be, but for your message U 141, you'd have the same Y####.CNM file as for the U 68.

[quote user="MartinB"] Today we started to get a couple of UID errors in Outlook 2003.

2 users connecting to the same IMAP account. Mercury v4.62.[/quote]

Well reading your post more carefully, I'd say one user moved the message to another folder, then moved it back again. Second client would notice the same message and indicate that the UID "changed unexpectedly". I've tested this with PDAs this spring, and simultaneous access over WebMail - and got that exact result on the PDA (Win Mobile 6 with Outlook).

[quote user="MartinB"] Today we started to get a couple of UID errors in Outlook 2003. <P>2 users connecting to the same IMAP account. Mercury v4.62.[/quote]</P> <P>Well reading your post more carefully, I'd say one user moved the message to another folder, then moved it back again. Second client would notice the same message and indicate that the UID "changed unexpectedly". I've tested this with PDAs this spring, and simultaneous access over WebMail - and got that exact result on the PDA (Win Mobile 6 with Outlook).</P>

The message wasn't moved. He got the error when he did a refresh on the folder.

 Not sure where to look for the message drop !!


DAVID: Please add IMAP filtering !

 

<p>The message wasn't moved. He got the error when he did a refresh on the folder.</p><p> Not sure where to look for the message drop !!</p><p> DAVID: Please add IMAP filtering ! </p><p> </p>

[quote user="MartinB"] The message wasn't moved. He got the error when he did a refresh on the folder.

 Not sure where to look for the message drop !![/quote]

maildrop is the same as the mailfolder aka mailbox. Maildrop is the proper name according to the RFCs.

If you're certain the refresh does this, then I'd enable session logging and look if something changes - plus make a backup of the maildrop before doing the refresh so you can check and compare the contents of the *.pnm files.

[quote user="MartinB"] The message wasn't moved. He got the error when he did a refresh on the folder. <P> Not sure where to look for the message drop !![/quote]</P> <P>maildrop is the same as the mailfolder aka mailbox. Maildrop is the proper name according to the RFCs.</P> <P>If you're certain the refresh does this, then I'd enable session logging and look if something changes - plus make a backup of the maildrop before doing the refresh so you can check and compare the contents of the *.pnm files.</P>

[quote user="Peter Strömblad"]A session log will not yield anything.[/quote]

Sorry Peter, but I have to take issue with this: a session log will tell me a considerable amount - most specifically, it will give me a context showing the sequence of commands that are being received, and the responses that are going out, without which it's very difficult for me to predict any kind of flow through the code.

-- David --

[quote user="Peter Strömblad"]A session log will not yield anything.[/quote] Sorry Peter, but I have to take issue with this: a session log will tell me a considerable amount - most specifically, it will give me a context showing the sequence of commands that are being received, and the responses that are going out, without which it's very difficult for me to predict any kind of flow through the code. -- David --

I won't get a chance to do this until Tuesday.

But I'll post back the details then.

Thanks

 IMAP FILTERING PLEASE

<p>I won't get a chance to do this until Tuesday.</p><p>But I'll post back the details then.</p><p>Thanks</p><p> IMAP FILTERING PLEASE </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft