(SIGH!) Problem with Outlook Contact.EntryID is back!

[Chris O''''Neill]

Awhile back, I had a problem grabbing the Outlook Contact.EntryID and saving
it in my table. I could grab the Contact.Parent.StoreID, but Outlook was
returning a ZLS for Contact.EntryID even though the Contact Item was created.
I need the Contact.EntryID so I can later pull up the Contact Item using
NameSpace.GetItemFromID(Contact.EntryID, Contact.Parent.StoreID).

After flailing around, I managed to resolve it, although I'm not sure what I
did to solve it (I was flailing at the time <g>). All was working fine up
until last night.

Last night, I converted my application from early binding (explicit
references) to late binding. Although I don't notice any performance
difference with late binding, my application is back to grabbing the
Contact.Parent.StoreID but returning a ZLS for the Contact.EntryID. (Sighing
and banging my head on my desk.....)

Without posting all the code, here's what I'm doing:

Dim objOutlook as Object
Dim nmsOutlookNameSpace as Object
Dim objContact as Object

Set objOutlook = CreateObject("Outlook.application")
Set nmsOutlookNameSpace = objOutlook.GetNamespace("MAPI")
Set objContact = objOutlook.CreateItem(olContactItem)

With objContact
[code to populate objContact here]
.Save
Me.txtOutlookContactID = objContact.EntryID
Me.txtOutlookContactParentID = objContact.Parent.StoreID
End With

As I said, the Contact Item *is* created (I can open Outlook and look at
it), so there *must* be a Contact.EntryID

Any ideas on what might be causing this to happen again? Also, isn't there
a way to just recursively search Outlook's Contact Items (using first and
last name, for instance) and pull out the EntryID ad Parent.StoreID that way?
(It seems to me that would be *much* easier than this!)

Thanks, yet again, for all the help and advice!

Regards, Chris

 

[Chris O''''Neill]

By the way, I'm developing on Access XP (2000) in case that makes a difference?

Also, I'm noticing that there's sometimes a delay before the contact item
shows up in Outlook. Sometimes the delay is very small, but once it was
quite awhile (maybe a minute or more?) before the contact appeared in Outlook.

Why is this????

Thanks, again...

Regards, Chris

 

[Chris O''''Neill]

Opps! Typo! Of course Access XP = Access 2002 (not 2000)

Mea culpa!

Chris

By the way, I'm developing on Access XP (2000) in case that makes a difference?

Also, I'm noticing that there's sometimes a delay before the contact item
shows up in Outlook. Sometimes the delay is very small, but once it was
quite awhile (maybe a minute or more?) before the contact appeared in Outlook.

Why is this????

Thanks, again...

Regards, Chris

Awhile back, I had a problem grabbing the Outlook Contact.EntryID and saving
it in my table. I could grab the Contact.Parent.StoreID, but Outlook was
returning a ZLS for Contact.EntryID even though the Contact Item was created.
I need the Contact.EntryID so I can later pull up the Contact Item using
NameSpace.GetItemFromID(Contact.EntryID, Contact.Parent.StoreID).

After flailing around, I managed to resolve it, although I'm not sure what I
did to solve it (I was flailing at the time <g>). All was working fine up
until last night.

Last night, I converted my application from early binding (explicit
references) to late binding. Although I don't notice any performance
difference with late binding, my application is back to grabbing the
Contact.Parent.StoreID but returning a ZLS for the Contact.EntryID. (Sighing
and banging my head on my desk.....)

Without posting all the code, here's what I'm doing:

Dim objOutlook as Object
Dim nmsOutlookNameSpace as Object
Dim objContact as Object

Set objOutlook = CreateObject("Outlook.application")
Set nmsOutlookNameSpace = objOutlook.GetNamespace("MAPI")
Set objContact = objOutlook.CreateItem(olContactItem)

With objContact
[code to populate objContact here]
.Save
Me.txtOutlookContactID = objContact.EntryID
Me.txtOutlookContactParentID = objContact.Parent.StoreID
End With

As I said, the Contact Item *is* created (I can open Outlook and look at
it), so there *must* be a Contact.EntryID

Any ideas on what might be causing this to happen again? Also, isn't there
a way to just recursively search Outlook's Contact Items (using first and
last name, for instance) and pull out the EntryID ad Parent.StoreID that way?
(It seems to me that would be *much* easier than this!)

Thanks, yet again, for all the help and advice!

Regards, Chris

 

[dch3]

1) Head out to a really good pub, or an even better Taverna. It won't solve
the problem, but it'll help with #2.

2) The EntryId and StoreId cannot be counted upon to retrieve a specific
item in Outlook. If the item is moved or if its parent is moved, there is the
possiblity that they'll change. Not neccessarily, but they can. They are
*NOT* the same as a primary key in a database.

3) For a lasting solution, either quit IT and open a pub, or an even better
Taverna, or post in the Outlook Newsgroup. The issue has come up multiple
times over there.

 

[dch3]

See
http://support.microsoft.com/kb/293152

http://www.outlookcode.com/article.aspx?id=19

Several years back, I was building an Access-based reservation system that I
wanted to create AppointmentItems in my Outlook and to update them as the
reservation changed. My solution was to create a custom property for the
AppointmentItem and assign the primary key from the main reservation table.
Then when I wanted to update the item, I simply searched through the items
looking for the key. It also allowed me to physically move an AppointmentItem

1) Head out to a really good pub, or an even better Taverna. It won't solve
the problem, but it'll help with #2.

2) The EntryId and StoreId cannot be counted upon to retrieve a specific
item in Outlook. If the item is moved or if its parent is moved, there is the
possiblity that they'll change. Not neccessarily, but they can. They are
*NOT* the same as a primary key in a database.

3) For a lasting solution, either quit IT and open a pub, or an even better
Taverna, or post in the Outlook Newsgroup. The issue has come up multiple
times over there.

Awhile back, I had a problem grabbing the Outlook Contact.EntryID and saving
it in my table. I could grab the Contact.Parent.StoreID, but Outlook was
returning a ZLS for Contact.EntryID even though the Contact Item was created.
I need the Contact.EntryID so I can later pull up the Contact Item using
NameSpace.GetItemFromID(Contact.EntryID, Contact.Parent.StoreID).

After flailing around, I managed to resolve it, although I'm not sure what I
did to solve it (I was flailing at the time <g>). All was working fine up
until last night.

Last night, I converted my application from early binding (explicit
references) to late binding. Although I don't notice any performance
difference with late binding, my application is back to grabbing the
Contact.Parent.StoreID but returning a ZLS for the Contact.EntryID. (Sighing
and banging my head on my desk.....)

Without posting all the code, here's what I'm doing:

Dim objOutlook as Object
Dim nmsOutlookNameSpace as Object
Dim objContact as Object

Set objOutlook = CreateObject("Outlook.application")
Set nmsOutlookNameSpace = objOutlook.GetNamespace("MAPI")
Set objContact = objOutlook.CreateItem(olContactItem)

With objContact
[code to populate objContact here]
.Save
Me.txtOutlookContactID = objContact.EntryID
Me.txtOutlookContactParentID = objContact.Parent.StoreID
End With

As I said, the Contact Item *is* created (I can open Outlook and look at
it), so there *must* be a Contact.EntryID

Any ideas on what might be causing this to happen again? Also, isn't there
a way to just recursively search Outlook's Contact Items (using first and
last name, for instance) and pull out the EntryID ad Parent.StoreID that way?
(It seems to me that would be *much* easier than this!)

Thanks, yet again, for all the help and advice!

Regards, Chris

 

[Chris O''''Neill]

1) Head out to a really good pub, or an even better Taverna. It won't solve
the problem, but it'll help with #2.

Although I quit drinking many years ago, I was seriously considering that
tonight.

2) The EntryId and StoreId cannot be counted upon to retrieve a specific
item in Outlook. If the item is moved or if its parent is moved, there is the
possiblity that they'll change. Not neccessarily, but they can. They are
*NOT* the same as a primary key in a database.

Yeah, I know. But up until now, that's been the only suggestion I've
received. I've mucked a bit tonight and managed to do a FirstName/LastName
search of the default contact folder to find a contact item (I'll post it
later), but that doesn't sound like a good idea either because of the
possibility of having more than one person with the same name.

3) For a lasting solution, either quit IT and open a pub, or an even better
Taverna, or post in the Outlook Newsgroup. The issue has come up multiple
times over there.

When this problem first appeared, I posted the question in the Outlook
Newsgroup and didn't receive any replies. Not to disparage another forum,
but I find this Newsgroup *much* friendlier and helpful. I will, however,
take another look over there and see what I can find.

Anyway, thanks for the reply. I'm still researching and working on it, so
I'm sure I'll eventually get this figured out.

Regards, Chris

 

[Chris O''''Neill]

See
http://support.microsoft.com/kb/293152

http://www.outlookcode.com/article.aspx?id=19

Thanks for those links. I'll go take a look.

Several years back, I was building an Access-based reservation system that I
wanted to create AppointmentItems in my Outlook and to update them as the
reservation changed. My solution was to create a custom property for the
AppointmentItem and assign the primary key from the main reservation table.
Then when I wanted to update the item, I simply searched through the items
looking for the key. It also allowed me to physically move an AppointmentItem
on my calendar and update the Access table.

Now *there's* a solution! I'm gonna have to research that one!

Thanks!

Regards, Chris

 

[dch3]

They're an interesting bunch. My general frustration with them is that it
seems as if you're less likely to get code samples and more likely to get a
hyperlink. More along the lines of 'I'd like to brew up some Jack Daniels'
and instead of getting the step-by-step you get the telephone number for the
Jack Daniels company.

Its mostly just getting used to them and their particular style.

 

[Chris O''''Neill]

They're an interesting bunch. My general frustration with them is that it
seems as if you're less likely to get code samples and more likely to get a
hyperlink.

That's fairly common here, too, although I don't really mind that. Handing
me code may solve the problem, but it doesn't go a long way in helping me
learn. Handing me a link forces me to research the issue at hand and come up
with the solution on my own. As well, I often come across other "tidbits" of
useful info while I'm researching a problem. Just handing me the code would
mean I wouldn't have found those golden nuggets.

Its mostly just getting used to them and their particular style.

Like everywhere else on the Net, eh? Anyway, I wasn't disparaging that
forum... I was just pointing out that I find this forum more active,
friendly and helpful. Btw, I did finally get one reply to my earlier query,
so posting there wasn't a total loss.

Regards, Chris

 

[Chris O''''Neill]

See
http://support.microsoft.com/kb/293152

http://www.outlookcode.com/article.aspx?id=19

Hmmmm.... pointing me to another site instead of just giving me the code.
Wouldja happen to have the phone number to the Jack Daniels company, too?


Seriously, though, you've *really* peaked my interest in the idea of using
a custom property and then searching for it. Eric Legault also pointed in
that direction over in the Outlook forum. Eric stated that I can use the
AdvancedSearch method to search multiple folder, in case the item has been
moved. I've done some reading in the Outlook VBA reference and the
AdvancedSearch method does look interesting although *very* complex.

Thank you for all the help and advice you've provided! I think I'm now
headed in the right direction, although it's going to take a bit more
research and effort before I get there.

Regards, Chris

P.S. I wouldn't *object* if you posted some sample code from your
reservations application showing how to create custom propertys and later
search for them using the AdvancedSearch method.

Several years back, I was building an Access-based reservation system that I
wanted to create AppointmentItems in my Outlook and to update them as the
reservation changed. My solution was to create a custom property for the
AppointmentItem and assign the primary key from the main reservation table.
Then when I wanted to update the item, I simply searched through the items
looking for the key. It also allowed me to physically move an AppointmentItem

1) Head out to a really good pub, or an even better Taverna. It won't solve
the problem, but it'll help with #2.

2) The EntryId and StoreId cannot be counted upon to retrieve a specific
item in Outlook. If the item is moved or if its parent is moved, there is the
possiblity that they'll change. Not neccessarily, but they can. They are
*NOT* the same as a primary key in a database.

3) For a lasting solution, either quit IT and open a pub, or an even better
Taverna, or post in the Outlook Newsgroup. The issue has come up multiple
times over there.

Awhile back, I had a problem grabbing the Outlook Contact.EntryID and saving
it in my table. I could grab the Contact.Parent.StoreID, but Outlook was
returning a ZLS for Contact.EntryID even though the Contact Item was created.
I need the Contact.EntryID so I can later pull up the Contact Item using
NameSpace.GetItemFromID(Contact.EntryID, Contact.Parent.StoreID).

After flailing around, I managed to resolve it, although I'm not sure what I
did to solve it (I was flailing at the time <g>). All was working fine up
until last night.

Last night, I converted my application from early binding (explicit
references) to late binding. Although I don't notice any performance
difference with late binding, my application is back to grabbing the
Contact.Parent.StoreID but returning a ZLS for the Contact.EntryID. (Sighing
and banging my head on my desk.....)

Without posting all the code, here's what I'm doing:

Dim objOutlook as Object
Dim nmsOutlookNameSpace as Object
Dim objContact as Object

Set objOutlook = CreateObject("Outlook.application")
Set nmsOutlookNameSpace = objOutlook.GetNamespace("MAPI")
Set objContact = objOutlook.CreateItem(olContactItem)

With objContact
[code to populate objContact here]
.Save
Me.txtOutlookContactID = objContact.EntryID
Me.txtOutlookContactParentID = objContact.Parent.StoreID
End With

As I said, the Contact Item *is* created (I can open Outlook and look at
it), so there *must* be a Contact.EntryID

Any ideas on what might be causing this to happen again? Also, isn't there
a way to just recursively search Outlook's Contact Items (using first and
last name, for instance) and pull out the EntryID ad Parent.StoreID that way?
(It seems to me that would be *much* easier than this!)

Thanks, yet again, for all the help and advice!

Regards, Chris

 

[dch3]

I've been tossing around the idea of finally putting together a website with
assorted tips & tricks and including a section on Access/Outlook integration.