FirstStrikeSolutions
asked on
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
I suppose the main outcome is to check the Reference to the Outlook object library and recompile.
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.
Make sure they're fully updated, with all relevant hotfixes and such.
ASKER
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.