View Full Version : Outlook Search is not very smart! Preventing duplicates


Banana
08-16-2007, 01:30 PM
I'm building a macro to copy some mail items in Outlook to a specified folder.

I'm trying to build in a check to ensure a same mailitem isn't being added more than once to that specified folder.

I have this code:
Private Function NoDuplicate(ByVal oFolder As Outlook.MAPIFolder, ByVal objItem As Outlook.MailItem) As Boolean

Dim RestrictedItems
Dim oFind As Outlook.MailItem
Dim oItems As Outlook.Items
Dim strSearch As String

Set oItems = oFolder.Items

strSearch = "[Subject] = """ & objItem.Subject & """ AND [CreationTime]= """ & Format(objItem.CreationTime, "ddddd h:nn AMPM") & """

Set oFind = oItems.Find(strSearch)

If oFind Is Nothing Then
NoDuplicate = True
Else
NoDuplicate = False
End If

End Function

Yet, I cannot get it to work. It runs through the code. In the immediate folder, I can check both objItem's creationtime and the actual mailitem's creationtime in that specified folder, and I can tell that they are exactly same.

Yet, the oFind returns as "Nothing" when it should have had that mailitem in the collection! What kind of twisted logic is going on there?!?

PS It still won't work with the Restrict method as well.

Banana
08-17-2007, 10:49 AM
*UGLY HACK*

Well, it doesn't look like Outlook has a key or something unique that I can latch on to do a comparison, or if there is, it trips the security model and sends that annoying dialog box. (That would make me very, very, very popular with my users, who *loves* to click on the dialog boxes... :rolleyes:)

The solution?

I do a comparison of subject line, and if they are same, do another comparison of CreationTime property. Now, if a copy is made, CreationTime property will change to the time it was copied, making comparison totally useless. Therefore, prior to copying, I take the CreationTime property from the original item and save it into copy's Mileage property.

If you're thinking, WTF is Mileage property, welcome to the club. It's a property that can accepts any strings, and is used to store information about miles traveled. Makes sense for a Appointment calendar, but not quite for a MailItem... But the MailItem doesn't have a Tag property, so Mileage property will have to do, as I know that nobody uses it in my office.

Nonetheless, this is still gambling on the fact and is not the wisest course. Hence me calling it ugly hack.

If anyone can suggest how one can uniquely identify a mailitem, I'd be much obliged.

*UGLY HACK*