URGENT!!! - MAPI Issues with vesion changes of Outlook and Access

[The Facilitator]

I am having an issue with a project I am involved in concerning a MAPI
folder. In the following snippet of code you will see that Access is
trying to connect to Outlook to import the tasks for analysis. The
original code was written in Access 2002, on a Win2K3 server. I had
to copy the database onto my laptop so that I could work on it off
site. My laptop has Office 2003 on Windows XP Pro. After I worked on
the database (without affecting any coding, I was working on the
reports and the switchboard), it will no longer work in Access 2002.
The file format is still Access 2000. The line of code that
generates the error is marked with stars after it. It seems it does
not like the version of MAPI on the original machine. I do not have
any choice, the client needs it on 2002 and no changes to any DLL's is
allowed, due to it being a secure environment. Their IT department
would have a fit it I suggested having to load other DLL's onto their
machines.

My question is, how do I re-point the database to the 2002 version of
MAPI, not the 2003. I had the same issue with using Outlook 2003 and
had to drop in the Outlook library version 11, which I can get away
with, but would also like to tell it to not use, just use version 10.
I have looked in references, in the ActiveX controls as well, and
nowhere can I find where it now needs to have a different version of
MAPI.

I realise MAPI is not actually part of either one of these softwares,
they are accessing it from the OS, so I even tried copying the MAPI
from my XP system onto the Win2K3 server, rebooted and still nothing.

Any help would be VERY appreciated. Thanks all.

Here is the code:

' Set up DAO objects (uses existing "tblCESPTasks" table)
Dim rst As DAO.Recordset
Set rst = CurrentDb.OpenRecordset("tblCESPTasks")


' Set up Outlook objects.
Dim ol As New Outlook.Application
Dim olns As Outlook.NameSpace
Dim cf As Outlook.MAPIFolder
Dim c As Outlook.TaskItem
Dim objItems As Outlook.Items
Dim prop As Outlook.UserProperty
Dim iNumContacts As Integer
Dim i As Integer

' Removes any tasks currently in tblCESPTasks
CleanTasks

Set olns = ol.GetNamespace("MAPI") ******************
Set cf = olns.GetDefaultFolder(olFolderTasks)
Set objItems = cf.Items
iNumContacts = objItems.Count
If iNumContacts <> 0 Then
For i = 1 To iNumContacts
If TypeName(objItems(i)) = "TaskItem" Then
Set c = objItems(i)
rst.AddNew

 

[Eric Legault [MVP - Outlook]]

Don't get hung up on MAPI, this isn't a MAPI issue! Nor do I think it's
related to the version of Access you are using or what version of Windows you
are working on or targeting. What's really critical is the error number and
description the GetNamespace call generates. AFAIR, that may occur if
Outlook hasn't finished loading yet.

Also, if you need to have this database run on computers that may have
earlier versions of Outlook, you need to set a reference to the Type Library
of the earliest Outlook version you need to support. Alternatively, use
late-binding and declare all your Outlook objects as Object.

 

[Mark Reed]

This is not because your references are wrong is it?

From the visual basic editor, click on Tools -> References and make sure you
have a reference to Microsoft Outlook (version number) Object library.

The versions change between each version of office!!!!.

Mark

 

[The Facilitator]

This happened once I clicked on the import function on my laptop
accidentally. Once I did that, Access would no longer accept the
v10.0 of the Outlook objects. That's why I went to the v11.0. After
that it worked fine for about a day. No matter what I tried, it would
not accept the v 10.0 , but it worked with v 11.0, even in the
Win2K3/Off2K2 environment.

Just as I was about to hand it over to the client, it came up with
"Error in loading DLL", which I traced back to the import component. I
put on a breakpoint just before the function runs and it stops at the
line

Set olns = ol.GetNamespace("MAPI")

and the error I get from within the module area is also Error in
loading DLL. I debug and it highlights that specific line.

On my laptop (with XP/2K3) it still runs just fine. When I load up
Office 2K3 onto the server, it runs fine.

Could it be that there is some v 11 code in the custom form that I
created for Outlook? I am not understanding how this could be, if I
designed it in 2K2, and it ran just fine in 2K2. I didn't add
anything to the form from 2K3.

I've also had the opportunity to test it out on another machine that
had Win2K/Off2K2 and it dod not work either. On this one I tried to
copy over the appropriate MAPI dll's into the Windows folder and I
rebooted. Still no luck.

I've done my best to isolate the problem and it does point to the MAPI
dll. Or at least it points to a dll that is being called when it
tries to get the MAPI namespace.

I've gone over the code to all the apps in this form and nothing is
amiss. I made sure that the code is the same in both machines. I've
done everything I can think of.

I hope this lengthy explanation helps someone see where my problem is.

Thank you for your help so far, and for any further help.

O

 

[Tim Marshall]

When I load up
Office 2K3 onto the server, it runs fine.

Oh dear, O, you might get some flak for that. Unless some of the big
guns here can tell me why I'm wrong, I'd never recommend having A2003 on
a server...

Note that I haven't followed this thread - this just caught my eye as I
was skimming through posts...

 

[The Facilitator]

There are only a few tasks in the Outlook mailbox, as it is only a
test environment. I have left it open so that there would be no lag.
It also does not GET to Outlook as whenever it did beforehands, it
would come up with the program accessing Outlook warning. The
following is the error information from the help file of the Access
2K2.

------------------------------------------------------------------------------------
Error in loading DLL (Error 48)


A dynamic link library (DLL) is a library specified in the Lib clause
of a Declare statement. This error has the following causes and
solutions:

The file isn't DLL-executable.
If the file is a source-text file, it must be compiled and linked to
DLL executable form.

The file isn't a Microsoft Windows DLL.
Obtain the Microsoft Windows DLL equivalent of the file.

The file is an early Microsoft Windows DLL that is incompatible with
Microsoft Windows protect mode.
Obtain an updated version of the DLL. ***************************

The DLL references another DLL that isn't present.
Obtain the referenced DLL and make it available to the other DLL.

The DLL or one of the referenced DLLs isn't in a directory specified
by your path.
Move the DLL to a referenced directory or place its current directory
on the path.

For additional information, select the item in question and press F1
(in Windows) or HELP (on the Macintosh).

--------------------------------------------------------------------------------------

The line with the stars after it, is what I am assuming is the problem
from this error. I have no non-M$ DLL's, no DLL's that I know of were
removed from the system, I never set anything in a Path statement in
the first place. This leaves incompatible version.

Needless to say, it was not the best of presentations to the client.

Thank you for the help so far, and any further help I receive.

O

 

[Ken Slovak - [MVP - Outlook]]

Import what?

This code is in Outlook VBA code?

The MAPI libraries are installed by Outlook, Simple MAPI can be installed by
Outlook Express, Eudora installs a version of MAPI, the term MAPI is rather
general. In this case it's Outlook MAPI that has to be dealt with. It's
always a good idea to make sure that Outlook is the default mail handler and
that it's installed correctly. So open IE, on Programs tab make sure Outlook
is the mail handler. Then run a Detect and Repair on your Office
installation.

Outlook MAPI is very version specific. So if you are developing in Access
2002 you will want to run an Office 2002 environment. If you develop on 2003
you must make sure you aren't using any methods, properties or events that
aren't in the earlier version. After you port back to the older environment
you must also make sure the project references are set correctly.

Never, ever run Outlook 2003 on an Exchange server. Do not do it. Outlook
2007 is OK for that. Earlier versions will corrupt the MAPI on the server
unless you really know what you're doing.

Instantiating a MAPI session failing like that has nothing to do with
pointing towards a certain version of MAPI. The high level connection you
are using with MAPI just depends on what version is registered and the
default MAPI handler. You aren't using a LoadDLL type thing and trying to
execute Extended MAPI functions like HrGetOneProp directly.

I've taken Outlook and Access applications back and forth among versions and
the best practice is really to develop in the earliest environment you need
to support. I use VM's with every Outlook/Office environment I need to
support so I can develop on any of them as needed. Usually I program
(addins) on an Office 2003 machine and compile on an Office 2000 VM. I'm
always adjusting project references and such, but you do need that earlier
environment available to be able to do that.

 

[Ken Slovak - [MVP - Outlook]]

It's installing Outlook on an Exchange server that's verboten.

 

[lyle fairfield]

Never, ever run Outlook <snips of other stuff which I shouldn't have
left out ...>

Great advice!

 

[Larry Linson]

Great advice!

Lyle, you are one of a kind!

Larry

 

[The Facilitator]

No coding was done in Outlook. This is what baffles me. The custom
Outlook form was developed in 2K2. No changes were done to any coding
when I brought it into the 2K3 environment. I opened the custom form
in Outlook 2K3 to check for any variance. Then I ran the import
utility in Access, but then I stopped it in Outlook, when the program
security window popped up. I did some minor changes to the Access
forms (no coding, just looks and links to reports and queries), but
again no module changes. When I brought it back to the 2K2
environment, it was asking for the Outlook 11.0 Object Library in
Access. I finally found it in the Office 2K3 CD, after flipping back
and forth between Office 2K3 and Office 2K2 in the server (in other
words, installing 2K3, removing it and re-installing 2K2, yeah, I
know...not a good thing to do). I installed the library and then
everything was working fine again in the 2K2 environment. The next
day "something" decided not to work. I know what MAPI does, as I am
primarily a Network Tech. If the MAPI problem was the issue, it
should have shown up when I changed over from Outlook Obj Lib 10.0 to
11.0. It didn't. I tested it out on a machine that did not have
Exchange on it, that was a standalone XP box with Off 2K2 to confirm
it was not a corruption of the MAPI dlls on the server when I upgraded
to 2K3 and then returned to 2K2. It runs fine on my XP box with Off
2K3 on it. I am getting to the point where I will need to go back to
an older version of the DB and recreate it. This would mean a couple
of long evenings worth of work, but this code was definitely all done
in 2K2, before it was brought into the 2K3 environment at all. Maybe
recreate the Outlook form? I am including it as an attachment, maybe
someone can see if there is something there? The thing is no coding
is done there. All the custom fields were already done in 2K2.

Thanks again for hate help so far, and for any new help offered.

Oliver

 

[Ken Slovak - [MVP - Outlook]]

If you move Outlook 2002 code to an Outlook 2003 environment the references
to Outlook are replaced with references to Outlook 2003. If you move it back
to Office 2002 you must re-set the references back to Outlook 2002. That's
all it takes. Otherwise the CLSID references to Outlook reference a version
not available on the Office 2002 box. That applies also to any Outlook code
in Access, where unless you are late-binding you are referencing the version
of Outlook on the dev box.

 

[The Facilitator]

The code is Access 2002 VBA importing task information from Outlook
2002, both standard and custom fields.

Thank you for the insight. I was able to clear it up by your (and
others suggestions) to clean up the library files in Access as they
pointed to some 2003 OLBs. Once I did that, I had everything working
on the test machine I was working on.
I now have a related problem. I was able to get the coding to work
flawlessly on the machine I set up, but when I went to install on the
client's workstation, I got the same Error loading DLL. So I went
into the code and sure enough it was stopped at the NameSpace("MAPI"),
yet again. So I went searching on the client's machine and found that
they have most of Office in 2002, but have Visio viewer and/or Project
2003 on the machines I will be copying to. The physical setup is also
different as the DB is on a mapped Network drive and they are running
it from a shortcut. I looked through the references and all was
working fine, nothing was missing.
Because they have the Visio viewer to look at email attachments, is
this affecting things? If not, what is the problem?

Again, thanks for all the help both received already and that I hope
to receive in the future.

O

 

[Ken Slovak - [MVP - Outlook]]

Visio and Project should not affect things.

I have no idea what the problem is other than an extension of the same
problems as before. I move code from Outlook 2000 to 2007 to all versions in
between without problems but I always make sure of what's being referenced
and what methods and properties I'm calling to only use those used in the
earliest version I plan to support.

The best approach however for most people is to develop on the same version
and the customer will use. That guarantees that no incompatibilities are
there.

 

[The Facilitator]

That is what I did with the test environment. The client is on a
Windows 2000 machine using office 2002 and using Exchange 2003. I
emulated that and have no issues on my system or any other system I
try, 2002, 2003, XP, etc. So the only thing to do is check with their
IT department to know exactly what changes may have been set up on
their systems and see where the differences are?

 

[Ken Slovak - [MVP - Outlook]]

Seeing what the differences are is the only way I think.