I am using VBA/Access to send SMTP mail using CDO. I set a reference to
"Microsoft CDO for Windows 2000 Library" (cdosys.dll). Everything works
fine, both on my PC and on another PC. However, on another PC that the
database was installed on, the user is getting the message, "The project
contains a missing or broken reference to the file 'CDO.DLL' version 1.21."
However, I don't have a reference to cdo.dll; my reference is to cdosys.dll.
The user has cdosys.dll, but doesn't have cdo.dll.

Any ideas as to what's going on?

Thanks!

Neil

[ Post a follow-up to this message ]

"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:N18ud.6954$0r.1310@newsread1.news.pas.earthlink.net...
>I am using VBA/Access to send SMTP mail using CDO. I set a reference to
>"Microsoft CDO for Windows 2000 Library" (cdosys.dll). Everything works
>fine, both on my PC and on another PC. However, on another PC that the
>database was installed on, the user is getting the message, "The project
>contains a missing or broken reference to the file 'CDO.DLL' version 1.21."
>However, I don't have a reference to cdo.dll; my reference is to
>cdosys.dll. The user has cdosys.dll, but doesn't have cdo.dll.
>
> Any ideas as to what's going on?

Try
regsvr32 cdosys.dll
b.t.w. is the cdosys.dll exactly the same on both machines?

> Thanks!
>
> Neil
>

[ Post a follow-up to this message ]

I just got some more information on this, and it's pretty interesting.

On my machine (development), I used "Microsoft CDO for Windows 2000 Library"
(cdosys.dll). Works fine.

The client using the db is in an office that uses Microsoft Exchange. On his
PC (in which there is no error and the code works fine), under references it
says, "Microsoft CDO for Microsoft Exchange" (cdoex.dll).

Now, when I delivered the database, the reference was to cdosys.dll. But
when he used it, somehow the reference got changed to cdoex.dll, though he
didn't do anything.

So does Windows just pick which is the best cdo dll to use, based on the
configuration? Since they're using Exchange, did it just replace the
reference to cdosys.dll with cdoex.dll? Seems kind of strange.

Anyway, getting back to the problem PC. Another PC on his LAN is the one
getting the error message. When we opened it up and looked at References, it
had two things: first was the reference to cdoex.dll, as was on the other
one; and the second was a reference to "Microsoft CDO Version 1.21"
(cdo.dll), which was indicated as "Missing."

So this PC not only changed cdosys.dll to cdoex.dll (as on the other PC),
but it also added a broken reference to cdo.dll. We removed the reference to
cdo.dll, and everything worked fine.

So, any idea as to what's going on, why these references are being swapped
out, and where the broken reference to cdo.dll came from?

Thanks!

Neil


"Egbert Nierop (MVP for IIS)" <egbert_nierop@nospam.invalid> wrote in
message news:%23en13Vo3EHA.2288@TK2MSFTNGP11.phx.gbl...
> "Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
> news:N18ud.6954$0r.1310@newsread1.news.pas.earthlink.net... 
>
> Try
> regsvr32 cdosys.dll
> b.t.w. is the cdosys.dll exactly the same on both machines?
> 
>

[ Post a follow-up to this message ]

"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:hKmud.7444$0r.5268@newsread1.news.pas.earthlink.net...
> I just got some more information on this, and it's pretty interesting.
>
> On my machine (development), I used "Microsoft CDO for Windows 2000
Library"
> (cdosys.dll). Works fine.
>
> The client using the db is in an office that uses Microsoft Exchange. On
his
> PC (in which there is no error and the code works fine), under references
it
> says, "Microsoft CDO for Microsoft Exchange" (cdoex.dll).
>
> Now, when I delivered the database, the reference was to cdosys.dll. But
> when he used it, somehow the reference got changed to cdoex.dll, though
he
> didn't do anything.
>
> So does Windows just pick which is the best cdo dll to use, based on the
> configuration? Since they're using Exchange, did it just replace the
> reference to cdosys.dll with cdoex.dll? Seems kind of strange.
>
> Anyway, getting back to the problem PC. Another PC on his LAN is the one
> getting the error message. When we opened it up and looked at References,
it
> had two things: first was the reference to cdoex.dll, as was on the other
> one; and the second was a reference to "Microsoft CDO Version 1.21"
> (cdo.dll), which was indicated as "Missing."
>
> So this PC not only changed cdosys.dll to cdoex.dll (as on the other PC),
> but it also added a broken reference to cdo.dll. We removed the reference
to
> cdo.dll, and everything worked fine.
>
> So, any idea as to what's going on, why these references are being
swapped
> out, and where the broken reference to cdo.dll came from?

You would be better off switching to late binding which doesn't require
that you set a reference at all. This offers the following benefits.

In most cases the code becomes version independent.  If you ask Windows to
create an object (for example) of "CDO.Message" then any registered library
capable of creating that object can be used.

In cases where no appropriate library exists in an application with a hard
reference you not only get an error when attempting to use that library,
but the reference marked "MISSING" will cause many built in Access
functions to fail.  So for lack of an Email library, the whole app might be
rendered useless.  With late binding, a PC that lacks an appropriate
library ONLY loses the abilities that the missing library provides.  The
rest of the app still works just fine.


--
I don't check the Email account attached
to this message.     Send instead to...
RBrandt    at       Hunter      dot      com

[ Post a follow-up to this message ]

One good thing about setting references is that it allows you specify an
order -- as with ADO and DAO -- with the first one being the default.

Anyway, so you're saying that if I omit the reference to CDO and just keep
the rest of the code the same, that it will automatically use the library,
as long as it's registered?

Neil


"Rick Brandt" <rickbrandt2@hotmail.com> wrote in message
news:31uecmF3eqva3U1@individual.net...
> "Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
> news:hKmud.7444$0r.5268@newsread1.news.pas.earthlink.net... 
> Library" 
> his 
> it 
> he 
> it 
> to 
> swapped 
>
> You would be better off switching to late binding which doesn't require
> that you set a reference at all. This offers the following benefits.
>
> In most cases the code becomes version independent.  If you ask Windows to
> create an object (for example) of "CDO.Message" then any registered
> library
> capable of creating that object can be used.
>
> In cases where no appropriate library exists in an application with a hard
> reference you not only get an error when attempting to use that library,
> but the reference marked "MISSING" will cause many built in Access
> functions to fail.  So for lack of an Email library, the whole app might
> be
> rendered useless.  With late binding, a PC that lacks an appropriate
> library ONLY loses the abilities that the missing library provides.  The
> rest of the app still works just fine.
>
>
> --
> I don't check the Email account attached
> to this message.     Send instead to...
> RBrandt    at       Hunter      dot      com
>
>

[ Post a follow-up to this message ]

"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:tCrud.7348$yr1.2836@newsread3.news.pas.earthlink.net...
> One good thing about setting references is that it allows you specify an
> order -- as with ADO and DAO -- with the first one being the default.
>
> Anyway, so you're saying that if I omit the reference to CDO and just keep
 the
> rest of the code the same, that it will automatically use the library, as 
long
> as it's registered?

No, you do have to make some minor modifications to the code.  Instead of...

Dim CDOMsg as CDO.Message
Set CDOMsg = New CDO.Message

...you use...

Dim CDOMsg as Object
Set CDOMsg = CreateObject("CDO.Message")

You also can't use named constants that are defined in the external library,
 but
instead have to substitute the literal value.

I usually add the reference to create the procedure so I can use the code
completion features of Access and after debugging, make the switch to late
binding.

--
I don't check the Email account attached
to this message.     Send instead to...
RBrandt    at       Hunter      dot      com

[ Post a follow-up to this message ]

"Rick Brandt" <rickbrandt2@hotmail.com> wrote in message
news:31v47jF3e2rvkU1@individual.net...
>
> "Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
> news:tCrud.7348$yr1.2836@newsread3.news.pas.earthlink.net... 
>
> No, you do have to make some minor modifications to the code.  Instead
> of...
>
> Dim CDOMsg as CDO.Message
> Set CDOMsg = New CDO.Message
>
> ...you use...
>
> Dim CDOMsg as Object
> Set CDOMsg = CreateObject("CDO.Message")
>
> You also can't use named constants that are defined in the external
> library, but instead have to substitute the literal value.

Surprise!
inside global.asa you can add a meta tag

<!--METADATA TYPE="TypeLib"
uuid={CD000000-8B95-11D1-82DB-00C04FB1625D}
-->

And now you have your constants imported.

> I usually add the reference to create the procedure so I can use the code

[ Post a follow-up to this message ]

VB/VBA will, under some circumstances, attempt to correct your
filename and version references: if you reference mydll ver 1.1.1
in your application folder, and on the target machine mydll
ver 1.1.2 is registered instead, and is in the Win Sys folder,
your application might attempt to use it. The critical link is
the GUID used to identify the object in the registry.

For example, if you try to load both Access 2002 and Access 2003,
you might find that you have actually loaded the A2003 version
or A2002 version of some file.

It often seems to cause problems: perhaps because we only notice
it when it has caused a problem.

(david)



"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:hKmud.7444$0r.5268@newsread1.news.pas.earthlink.net...
> I just got some more information on this, and it's pretty interesting.
>
> On my machine (development), I used "Microsoft CDO for Windows 2000
Library"
> (cdosys.dll). Works fine.
>
> The client using the db is in an office that uses Microsoft Exchange. On
his
> PC (in which there is no error and the code works fine), under references
it
> says, "Microsoft CDO for Microsoft Exchange" (cdoex.dll).
>
> Now, when I delivered the database, the reference was to cdosys.dll. But
> when he used it, somehow the reference got changed to cdoex.dll, though he
> didn't do anything.
>
> So does Windows just pick which is the best cdo dll to use, based on the
> configuration? Since they're using Exchange, did it just replace the
> reference to cdosys.dll with cdoex.dll? Seems kind of strange.
>
> Anyway, getting back to the problem PC. Another PC on his LAN is the one
> getting the error message. When we opened it up and looked at References,
it
> had two things: first was the reference to cdoex.dll, as was on the other
> one; and the second was a reference to "Microsoft CDO Version 1.21"
> (cdo.dll), which was indicated as "Missing."
>
> So this PC not only changed cdosys.dll to cdoex.dll (as on the other PC),
> but it also added a broken reference to cdo.dll. We removed the reference
to
> cdo.dll, and everything worked fine.
>
> So, any idea as to what's going on, why these references are being swapped
> out, and where the broken reference to cdo.dll came from?
>
> Thanks!
>
> Neil
>
>
> "Egbert Nierop (MVP for IIS)" <egbert_nierop@nospam.invalid> wrote in
> message news:%23en13Vo3EHA.2288@TK2MSFTNGP11.phx.gbl... 
>
>

[ Post a follow-up to this message ]

Yes; but in this case we're talking about different dlls altogether:
cdosys.dll being replaced with cdoex.dll in the application; and (in one
case) a broken reference to cdo.dll that I didn't place there!

Neil

"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:41bcf3d0$0$21874$61ce578d@news.syd.swiftdsl.com.au...
> VB/VBA will, under some circumstances, attempt to correct your
> filename and version references: if you reference mydll ver 1.1.1
> in your application folder, and on the target machine mydll
> ver 1.1.2 is registered instead, and is in the Win Sys folder,
> your application might attempt to use it. The critical link is
> the GUID used to identify the object in the registry.
>
> For example, if you try to load both Access 2002 and Access 2003,
> you might find that you have actually loaded the A2003 version
> or A2002 version of some file.
>
> It often seems to cause problems: perhaps because we only notice
> it when it has caused a problem.
>
> (david)
>
>
>
> "Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
> news:hKmud.7444$0r.5268@newsread1.news.pas.earthlink.net... 
> Library" 
> his 
> it 
> it 
> to 
>
>

[ Post a follow-up to this message ]

Have you checked the GUID values for those objects? I understand
the importance which you place on filenames, but that is not
actually how the system was intended to work.

(david)

"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:iudvd.9467$yr1.7546@newsread3.news.pas.earthlink.net...
> Yes; but in this case we're talking about different dlls altogether:
> cdosys.dll being replaced with cdoex.dll in the application; and (in one
> case) a broken reference to cdo.dll that I didn't place there!
>
> Neil
>
> "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
> news:41bcf3d0$0$21874$61ce578d@news.syd.swiftdsl.com.au... 
On[vbcol=seagreen] 
references[vbcol=seagreen] 
But[vbcol=seagreen] 
the[vbcol=seagreen] 
one[vbcol=seagreen] 
References,[vbcol=seagreen] 
other[vbcol=seagreen] 
PC),[vbcol=seagreen] 
reference[vbcol=seagreen] 
to[vbcol=seagreen] 
works[vbcol=seagreen] 
the[vbcol=seagreen] 
to[vbcol=seagreen] 
>
>

[ Post a follow-up to this message ]