• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 268
  • Last Modified:

Problems using the VBA API to Outlook 2013 from a 2003 era application

I have an existing application which is native to 2003 (mde format) which uses the Outlook API to synchronize meetings in the outlook calendar with my application database. It has worked fine in the past, interacting normally with Outlook 2007 and 2010 instances, but I now have a client using Outlook 2013 with Office 365 licencing and the process crashes with an obscure error. There is also a process which synchronizes contacts and that runs fine too. Everything is 32-bit - the application and the Office 2013 installation, etc.

Can anyone point me to any documentation on what might have changed with the API as far as compatibility to Outlook 2013? I found some references to recent API changes, but nothing relating to the methods and properties I'm using.
0
FirstStrikeSolutions
Asked:
FirstStrikeSolutions
  • 4
  • 3
3 Solutions
 
Jeffrey CoachmanCommented:
Not sure, ...but note that you are trying to bridge a 10 year gap in technology here.

Also, note that it may be outlook causing the issue here because it is "profile based"

Does the Access 2003 MDB file work correctly with Acc 2013/365?

Have you tried crating an .accde file in 2013 and using that instead of the 2003 MDE file?


Lets see what other Experts may post.

JeffCoachman
0
 
FirstStrikeSolutionsAuthor Commented:
Hi Jeff.

Yes, the application works fine with Access 2013 under 365 (as long as it's 32-bit due to some third party activeX objects). Even the contact synch function works ok in the same installation. I assume that there is some change in the API or the "meeting/event" data structure in Outlook 2013 calendar. I expect I will need to update the code to allow for the change, so maybe I will end up needing two versions - or try to detect the Outlook version and adjust accordingly in the code.

Making an accde is an option but is a pain since I would need to compile and distribute multiple versions. Some clients use 2003 still, otherwise, I would have done that some time ago. I actually develop in Access 2010 and then switch to 2003 to compile for distribution as an mde. I have a few tricks in the coding to behave a little differently when in 2007 and later (to handle form resizing in particular).

My next step is to get an mdb copy of the application to the client site and debug it. I don't like doing that, but I think I can trust the client and delete it fully afterwards to avoid leaving the source code in the "open". At least that might tell me the exact call which is triggering the obscure and unhelpful error message.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
What error are you getting?

When you refer to the "Outlook API", what exactly do you mean. Are you using MAPI calls (which is the Mail API, which is essentially the Outlook API) or are you using Automation (i.e. creating items in VBA code using CreateObject and such).

2013 has presented some challenges, since a lot of Outlook functionality is moving to the cloud with O365 stuff. In some cases, we've heard reports that Automation processes fail with O365 Outlook.

FWIW, 2013 does expose an API: https://msdn.microsoft.com/en-us/library/office/jj900714(v=office.15).aspx
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
FirstStrikeSolutionsAuthor Commented:
I note that on the MSDN, there is mention of 2013 not coexisting with 2003 and earlier. Perhaps I am using an element which relates to 2003 and just need to find a more up-to-date version of the same thing. Hopefully it will still work with earlier Outlook installations. I need to get access to the client site to trace it, so will update later this week.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Versions of Access 2003 and earlier do not coexist with newer versions. In fact, most experienced devs have moved to using virtual machines to run multiple versions on the same machine.

That said - most elements of 2003 would "upgrade" to 2013, assuming you're not using the cloud-based version of Outlook (i.e. Outlook.com). If your workstations have Outlook actually installed on their desktop, then you should be okay. If not, and if the users are using the cloud based version only, then you'll have to rewrite the application to use those new APIs for the cloud.
0
 
FirstStrikeSolutionsAuthor Commented:
OK, so I fixed the problem but not sure exactly how...

I copied the uncompiled MDB file to the client site and ran it in debug mode. Initially got the same error ("Call failed" with an obscure negative integer which looks like an address, not an error number). It looks like a mismatch between the VBA core module and the object library, rather than a message from it because it is very generic.

It was finding Appointment items ok but failing on the first reference to the Body property. That's the main text content of the appointment, so nothing which is likely to have changed between versions of the Outlook API. Then tracing it through to find which record it fails on (in case there was something funky about the value of a particular appointment), it ran through fine and finished correctly, doing everything as normal, deleting old appointments and creating new ones!

Checking the References, it was now pointing to the Outlook 15 Object Library (MSOUTL.OLB). Obviously, there is a mechanism in the Office configuration which moves this reference to the current version of Outlook, as my development one switches between Office 14 and Office 11 when I switch versions to build the common distribution. Thus, it appears to be a problem with distributing an MDE with a reference to an older copy of Outlook not being converted automatically - possibly because an MDE cannot be re-compiled.

I'm thinking that perhaps I can distribute the MDB version of that anyway as it's only an add-on application to the main product, and perhaps build the shortcut with the /decompile flag to force recompile each time it is run (it's not that big that it would delay the program start significantly).

Any follow-up insights welcome.
0
 
FirstStrikeSolutionsAuthor Commented:
I suppose the main outcome is to check the Reference to the Outlook object library and recompile.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Access is able to upgrade references regardless of whether you have a MDB or MDE file, so I'd assume your client has troubles with their installation of Windows or Office (or both).

Make sure they're fully updated, with all relevant hotfixes and such.
0

Featured Post

Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now