MS Access DLLs, OCXs, References

[SAM]

Hi everyone,

I consider myself a very competent programmer when it comes to actual
programming and analyzing the business that I'm modelling. I am now
crossing into what I would consider Access admin/config territory, an
area
where I generally suck at.

Here is my problem. I do all my programming on my laptop before
giving
the mdb files to my clients. Virtually everything works on my
machine, but
the simplest things stop working when I move my files to another
computer.
I'm pretty sure that it has something to do with changed file paths
and missing DLLs and OCXs. I'm running Access 2003.

Some of the most basic functionality that stops are the LEFT, RIGHT,
MID, FORMAT, and CHR functions. Those are the ones I use mostly,
anyway. I'm sure others are knocked out too. There is a simple
workaround where I just put "VBA." in front all those functions.
Unfortunately, if I use those functions directly in a query, even the
"VBA." does not help. I have to create a module to call the VBA.LEFT
function and return the string to the query. Not an elegant or ideal
solution, but at least it gets the job done without wasting too much
time. I would expect that this is a simple fix.

I have incorporated a lot of cool functionality and objects into
various
projects including the Common Dialog Box, FileSystemObject, Faxing,
Emailing,
Depending on the machine that I load files to, different functionality
gets
knocked out. It doesn't appear to be consistent. Everyone's list of
references
are slightly different and I am having a tough time locating a
specific reference or closely-related reference to replace the missing
one.

First question. Why does this happen in the first place. My laptop
is dual boot and all my work files and applications are on the D: Boot
Partition. That may have something to do with it. Most of my clients
are on C:. I'm using Windows 2K Server, my clients are mostly using
XP. If I do have to repoint DLLS, OCXs, and references, how do I do
that for Access? Come to think of it, this is also happening to my VB
6.0 projects. I've only noticed the CHR, etc issues so far there.

Second question. Does a particular install (typical/full/custom)
affect the amount of dlls, ocxs, etc loaded into the computer. Does
the OS matter? Why do machines have different lists (missing what
default installs I have rather than me not registering new stuff)?

FYI, here are the references in order that I'm using on my machine.
Everything that I have programmed works. There may some extraneous
ones, but "If it ain't broke, don't mess with it". If anyone can give
me or point me to a document or link that explains what references
contain that would be great.

Visual Basic For Applications
Microsoft Access 11.0 Object Library
Microsoft DAO 3.6 Object Library
Microsoft ActiveX Data Objects 2.5 Library
OLE Automation
*faxadmin 1.0 type library
faxcom 1.0 type library
*Microsoft CDO For Windows 2000 Library
Microsoft CDO For NTS 1.2 Library
Microsoft Scripting Runtime
Microsoft Visual Basic For Applications Extensibility 5.3
*Microsoft Common Dialog Control 6.0 (SP3)
Utility

The ones marked with "*" are the ones listed as missing on my client's
machine. As expected, my dialog box doesn't work. However, that
doesn't explain why my file system code and basic functions stop
working.

If someone could give me a quick References 101 course here, point me
to a good
white paper/book, or just provide the magic answer, that would be
appreciated.

Thanks. SAM

[Rick Brandt]

SAM wrote:

Hi everyone,

I consider myself a very competent programmer when it comes to actual
programming and analyzing the business that I'm modelling. I am now
crossing into what I would consider Access admin/config territory, an
area
where I generally suck at.

Here is my problem. I do all my programming on my laptop before
giving
the mdb files to my clients. Virtually everything works on my
machine, but
the simplest things stop working when I move my files to another
computer.
I'm pretty sure that it has something to do with changed file paths
and missing DLLs and OCXs. I'm running Access 2003.

Some of the most basic functionality that stops are the LEFT, RIGHT,
MID, FORMAT, and CHR functions. Those are the ones I use mostly,
anyway. I'm sure others are knocked out too. There is a simple
workaround where I just put "VBA." in front all those functions.
Unfortunately, if I use those functions directly in a query, even the
"VBA." does not help. I have to create a module to call the VBA.LEFT
function and return the string to the query. Not an elegant or ideal
solution, but at least it gets the job done without wasting too much
time. I would expect that this is a simple fix.

I have incorporated a lot of cool functionality and objects into
various
projects including the Common Dialog Box, FileSystemObject, Faxing,
Emailing,
Depending on the machine that I load files to, different functionality
gets
knocked out. It doesn't appear to be consistent. Everyone's list of
references
are slightly different and I am having a tough time locating a
specific reference or closely-related reference to replace the missing
one.

First question. Why does this happen in the first place. My laptop
is dual boot and all my work files and applications are on the D: Boot
Partition. That may have something to do with it. Most of my clients
are on C:. I'm using Windows 2K Server, my clients are mostly using
XP. If I do have to repoint DLLS, OCXs, and references, how do I do
that for Access? Come to think of it, this is also happening to my VB
6.0 projects. I've only noticed the CHR, etc issues so far there.

Second question. Does a particular install (typical/full/custom)
affect the amount of dlls, ocxs, etc loaded into the computer. Does
the OS matter? Why do machines have different lists (missing what
default installs I have rather than me not registering new stuff)?

FYI, here are the references in order that I'm using on my machine.
Everything that I have programmed works. There may some extraneous
ones, but "If it ain't broke, don't mess with it". If anyone can give
me or point me to a document or link that explains what references
contain that would be great.

Visual Basic For Applications
Microsoft Access 11.0 Object Library
Microsoft DAO 3.6 Object Library
Microsoft ActiveX Data Objects 2.5 Library
OLE Automation
*faxadmin 1.0 type library
faxcom 1.0 type library
*Microsoft CDO For Windows 2000 Library
Microsoft CDO For NTS 1.2 Library
Microsoft Scripting Runtime
Microsoft Visual Basic For Applications Extensibility 5.3
*Microsoft Common Dialog Control 6.0 (SP3)
Utility

The ones marked with "*" are the ones listed as missing on my client's
machine. As expected, my dialog box doesn't work. However, that
doesn't explain why my file system code and basic functions stop
working.

If someone could give me a quick References 101 course here, point me
to a good
white paper/book, or just provide the magic answer, that would be
appreciated.

Thanks. SAM

When distributing an Access app to multiple PCs every effort should be made to
add ZERO additional references or you face exactly these issues.

Switch your code to late binding, delete all of those references, and your
problems are greatly reduced if not eliminated. At least then a missing library
only affects calls to that library and don't mess anything else up.

In addition many of the things you are using like FSO and Common Dialog can
nearly always be replaced with API calls that make using those libraries
unnecessary.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[SAM]

"Rick Brandt" <ri*********@hotmail.com> wrote in message news:<37*************@individual.net>...

SAM wrote:

Hi everyone,

I consider myself a very competent programmer when it comes to actual
programming and analyzing the business that I'm modelling. I am now
crossing into what I would consider Access admin/config territory, an
area
where I generally suck at.

Here is my problem. I do all my programming on my laptop before
giving
the mdb files to my clients. Virtually everything works on my
machine, but
the simplest things stop working when I move my files to another
computer.
I'm pretty sure that it has something to do with changed file paths
and missing DLLs and OCXs. I'm running Access 2003.

Some of the most basic functionality that stops are the LEFT, RIGHT,
MID, FORMAT, and CHR functions. Those are the ones I use mostly,
anyway. I'm sure others are knocked out too. There is a simple
workaround where I just put "VBA." in front all those functions.
Unfortunately, if I use those functions directly in a query, even the
"VBA." does not help. I have to create a module to call the VBA.LEFT
function and return the string to the query. Not an elegant or ideal
solution, but at least it gets the job done without wasting too much
time. I would expect that this is a simple fix.

I have incorporated a lot of cool functionality and objects into
various
projects including the Common Dialog Box, FileSystemObject, Faxing,
Emailing,
Depending on the machine that I load files to, different functionality
gets
knocked out. It doesn't appear to be consistent. Everyone's list of
references
are slightly different and I am having a tough time locating a
specific reference or closely-related reference to replace the missing
one.

First question. Why does this happen in the first place. My laptop
is dual boot and all my work files and applications are on the D: Boot
Partition. That may have something to do with it. Most of my clients
are on C:. I'm using Windows 2K Server, my clients are mostly using
XP. If I do have to repoint DLLS, OCXs, and references, how do I do
that for Access? Come to think of it, this is also happening to my VB
6.0 projects. I've only noticed the CHR, etc issues so far there.

Second question. Does a particular install (typical/full/custom)
affect the amount of dlls, ocxs, etc loaded into the computer. Does
the OS matter? Why do machines have different lists (missing what
default installs I have rather than me not registering new stuff)?

FYI, here are the references in order that I'm using on my machine.
Everything that I have programmed works. There may some extraneous
ones, but "If it ain't broke, don't mess with it". If anyone can give
me or point me to a document or link that explains what references
contain that would be great.

Visual Basic For Applications
Microsoft Access 11.0 Object Library
Microsoft DAO 3.6 Object Library
Microsoft ActiveX Data Objects 2.5 Library
OLE Automation
*faxadmin 1.0 type library
faxcom 1.0 type library
*Microsoft CDO For Windows 2000 Library
Microsoft CDO For NTS 1.2 Library
Microsoft Scripting Runtime
Microsoft Visual Basic For Applications Extensibility 5.3
*Microsoft Common Dialog Control 6.0 (SP3)
Utility

The ones marked with "*" are the ones listed as missing on my client's
machine. As expected, my dialog box doesn't work. However, that
doesn't explain why my file system code and basic functions stop
working.

If someone could give me a quick References 101 course here, point me
to a good
white paper/book, or just provide the magic answer, that would be
appreciated.

Thanks. SAM

When distributing an Access app to multiple PCs every effort should be made to
add ZERO additional references or you face exactly these issues.

Switch your code to late binding, delete all of those references, and your
problems are greatly reduced if not eliminated. At least then a missing library
only affects calls to that library and don't mess anything else up.

In addition many of the things you are using like FSO and Common Dialog can
nearly always be replaced with API calls that make using those libraries
unnecessary.

Yes, I'm beginning to see that now. I'm usually wrapped in solving a
business or logical problem and rarely worrying about my applications
working elsewhere. Usually my projects are managed my me and people
get reports or whatever. Now that they're finding my tools and
mini-apps are useful for other parts of the business, they want me to
roll them out. So, now I HAVE to deal with this. BTW, my main
background is scientific research. I have programmed in VB/Access for
about 5 years on a small scale to do very specific (and sometimes very
sophisticated) things for my clients...mostly centered around data
analysis and reporting. However, most of that could be done with the
default Access file since it was all about logic. Now people want
cool features (email, fax, file management, etc). I've always wanted
to work on a bigger project, but I have found things to be much more
interesting on the business side, lately.

So, what do you mean exactly by LATE BINDING? I can dereference the
libraries down to the basic 4 or 5 that Access gives you by default.
I have just gone to Google and I have seen code snippets of API work
arounds for FSO and Common Dialog. I'm thinking of switching those
over ASAP. If there is an API way of handling EMAIL and FAX, that
would take care of most of what my clients ask for now. I currently
use CDO for that and if what you say continues to be true, then CDO
will smack me in the head sooner or later.

Thanks for your quick reply. SAM

[Rick Brandt]

"SAM" <ga*********@hotmail.com> wrote in message
news:98**************************@posting.google.c om...

So, what do you mean exactly by LATE BINDING? I can dereference the
libraries down to the basic 4 or 5 that Access gives you by default.
I have just gone to Google and I have seen code snippets of API work
arounds for FSO and Common Dialog. I'm thinking of switching those
over ASAP. If there is an API way of handling EMAIL and FAX, that
would take care of most of what my clients ask for now. I currently
use CDO for that and if what you say continues to be true, then CDO
will smack me in the head sooner or later.

Thanks for your quick reply. SAM

If you Google these groups on the term "Late Binding" you will get a great deal
of examples. Essentially Late Binding passes the creation of the object to
Windows. With early binding...

Dim MyObj as Excel.Application

....you have added a ref to the Excel library and are telling Access to go to
that *specific* library and instantiate an instance of an Excel object. With
late binding..

Dim MyObj as Object
Set MyObj = CreateObject("Excel.Application")

....your code is asking the OS to create an Excel object using whatever library
that the system registry dictates is the correct one to use.

One of the biggest advantages initially is that the library doesn't have to be
the same on all PCs. All that is required is that *some* library be present
that can create an Excel object. This means that your code is now version
independent since Excel 97 works as well as Excel 2003 for this purpose. Of
course you could be trying to do something in Excel that is only supported in a
particular version, but that is fairly rare.

It is relatively easy to switch from early to late binding and in fact most
developers recommend starting out with early binding while building the code and
then switching to late binding at the end. The reason for this is that early
binding gives you the intellisense code-completion capabilities and mistakes can
be caught at compile time that would otherwise have to be caught at runtime.
Once the code is working and thoroughly tested you can then make the necessary
changes to make it work with late binding.

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