understading references in MS Access

[WindAndWaves]

Hi Gurus

I have recently discovered references in the VB section of MS Access,
however, when choosing references, I noticed that there are more than who
knows how many options. How and/or where do you i get more information on
all the references available? Are there any that I should be using / should
be avoiding (I know about the DAO stuff)?

Keen to hear any suggestions.

TIA

- Nicolaas

[Rick Brandt]

"WindAndWaves" <ac****@ngaru.com> wrote in message
news:Jt********************@news.xtra.co.nz...

Hi Gurus

I have recently discovered references in the VB section of MS Access,
however, when choosing references, I noticed that there are more than who
knows how many options. How and/or where do you i get more information on
all the references available? Are there any that I should be using / should
be avoiding (I know about the DAO stuff)?

Keen to hear any suggestions.

In my opinion you should avoid ALL of them.

I should qualify that. Open a new blank file and look at the three or four
references that are set by default. Those are all you should ever need. If you
build functionality that is dependent on other references you will have nothing
but grief if you try to use those files on PCs besides the development box.

On the rare occasion that you need to automate an outside library use late
binding which doesn't require a hard reference and you will have a much easier
time when distributing to multiple target machines.

Also don't be confused into thinking that what you are seeing is a "list of
references provided by Access that you can add to your Access app". It is
actually a list of registered libraries on your Windows OS. There is no
implication that you should (or even can) use all of them in your Access app.
The same applies to the "additional tools" toolbar that is available in form and
report design. That is a list of all registered ActiveX controls on your
system, but only a small minority of them are compatible with Access.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Jack MacDonald]

You should include only the references that are necessary for your
application. If you distribute an application to a machine that does
not have the reference installed, then your application will fail.

On Tue, 12 Oct 2004 11:06:32 +1300, "WindAndWaves" <ac****@ngaru.com>
wrote:

Hi Gurus

I have recently discovered references in the VB section of MS Access,
however, when choosing references, I noticed that there are more than who
knows how many options. How and/or where do you i get more information on
all the references available? Are there any that I should be using / should
be avoiding (I know about the DAO stuff)?

Keen to hear any suggestions.

TIA

- Nicolaas

**********************
ja**************@telusTELUS.net
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security

[WindAndWaves]

"Jack MacDonald" <ja**************@telus.net> wrote in message
news:36********************************@4ax.com...

You should include only the references that are necessary for your
application. If you distribute an application to a machine that does
not have the reference installed, then your application will fail.

Thank you for your answer. I have some more questions:

Is there a way to 'attach' the libraries when distributing a database?

I am sure that some of these libraries are super useful, if only I knew how
to use them.
TIA

- Nicolaas

[WindAndWaves]

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:2t*************@uni-berlin.de...

"WindAndWaves" <ac****@ngaru.com> wrote in message
news:Jt********************@news.xtra.co.nz...

Hi Gurus

I have recently discovered references in the VB section of MS Access,
however, when choosing references, I noticed that there are more than who knows how many options. How and/or where do you i get more information on all the references available? Are there any that I should be using / should be avoiding (I know about the DAO stuff)?

Keen to hear any suggestions.
In my opinion you should avoid ALL of them.

I should qualify that. Open a new blank file and look at the three or

four references that are set by default. Those are all you should ever need. If you build functionality that is dependent on other references you will have nothing but grief if you try to use those files on PCs besides the development box.
On the rare occasion that you need to automate an outside library use late
binding which doesn't require a hard reference and you will have a much easier time when distributing to multiple target machines.

Also don't be confused into thinking that what you are seeing is a "list of references provided by Access that you can add to your Access app". It is
actually a list of registered libraries on your Windows OS. There is no
implication that you should (or even can) use all of them in your Access app. The same applies to the "additional tools" toolbar that is available in form and report design. That is a list of all registered ActiveX controls on your
system, but only a small minority of them are compatible with Access.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Thank you for your answer. I have some more questions:

Is there a way to 'attach' the libraries when distributing a database?

I am sure that some of these libraries are super useful, if only I knew how
to use them.
TIA

- Nicolaas

[Tony Toews]

"WindAndWaves" <ac****@ngaru.com> wrote:

Thank you for your answer. I have some more questions:

Is there a way to 'attach' the libraries when distributing a database?

I am sure that some of these libraries are super useful, if only I knew how
to use them.

This is the biggest problem with using "libraries" or references. The user may
already have that same DLL/OCX on their system but a newer/older version. If they
install your newer version another app on their system may puke. If they keep the
newest version then your app may puke.

Also you may not be, likely aren't, allowed to redistribute many of these either.
They are licensed from some app on your system. But you can't turn around and send
them off.

Finally most of them won't work in Access anyhow.

Many ActiveX controls do not work inside MS Access unless the vendor specifically
states that they do support Access. In which case they will likely also have sample
code on their website. For more details see the following Knowledge Base articles at
support.microsoft.com.

ACC97: Custom ActiveX Control Features Supported in MS Access 97 - 164241
ACC97: ActiveX Controls List Doesn't Show All ActiveX Controls - 174964
ACC2000: Custom ActiveX Control Features Supported in Access - 202104
ACC2000: Supported ActiveX Controls for Microsoft Access 2000 - 208283

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[WindAndWaves]

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:o9********************************@4ax.com...

"WindAndWaves" <ac****@ngaru.com> wrote:

Thank you for your answer. I have some more questions:

Is there a way to 'attach' the libraries when distributing a database?

I am sure that some of these libraries are super useful, if only I knew howto use them.
This is the biggest problem with using "libraries" or references. The

user may already have that same DLL/OCX on their system but a newer/older version. If they install your newer version another app on their system may puke. If they keep the newest version then your app may puke.

Also you may not be, likely aren't, allowed to redistribute many of these either. They are licensed from some app on your system. But you can't turn around and send them off.

Finally most of them won't work in Access anyhow.

Many ActiveX controls do not work inside MS Access unless the vendor specifically states that they do support Access. In which case they will likely also have sample code on their website. For more details see the following Knowledge Base articles at support.microsoft.com.

ACC97: Custom ActiveX Control Features Supported in MS Access 97 - 164241
ACC97: ActiveX Controls List Doesn't Show All ActiveX Controls - 174964
ACC2000: Custom ActiveX Control Features Supported in Access - 202104
ACC2000: Supported ActiveX Controls for Microsoft Access 2000 - 208283

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

So then it really would be best to ditch all the references. Oh well. I
will do my best to get rid of as many as possible in my application.

at the moment, I use:

visual basic for applications
MS Access 11.0 object lib.
Ole automation
MS DAO 3.6
MS ActiveX Data objects 2.5 Library
MS office 11.0 object lib
MS shell controls and automation
MS outlook 11.0 object lib

[Larry Linson]

"WindAndWaves" wrote

So then it really would be best to
ditch all the references. Oh well. I
will do my best to get rid of as many
as possible in my application.
No, only those that you don't need.
at the moment, I use:

visual basic for applications
MS Access 11.0 object lib.
Ole automation
MS DAO 3.6
MS ActiveX Data objects 2.5 Library
MS office 11.0 object lib
MS shell controls and automation
MS outlook 11.0 object lib

Unless you actually use ADO code, you can uncheck the MS ActiveX Data
Objects 2.5 Library. And you may be able to uncheck the Office Lib and
Outlook Lib unless you are automating other apps. I don't know about the
"shell controls" -- I don't have them in my test application for Access
2003.

Larry Linson
Microsoft Access MVP

[John Mishefske]

WindAndWaves wrote:

"Jack MacDonald" <ja**************@telus.net> wrote in message
news:36********************************@4ax.com...

You should include only the references that are necessary for your
application. If you distribute an application to a machine that does
not have the reference installed, then your application will fail.

Thank you for your answer. I have some more questions:

Is there a way to 'attach' the libraries when distributing a database?

The answer is it depends. If the reference is to code you created and
that you intend to provide and register with the operating system then
perhaps yes but if it is software (like Outlook or Office) that the
customer installs then no. (That's a general answer and exceptions
exist).

References allows VBA to work with software (code) that is not part of
Access. But there are licensing issues; you can't distribute Office
with your application - you can provide the reference that would allow
VBA to work with it.

But that software may not be installed where the reference expects it
or it may not be version you have on your development PC.

You can avoid these problems using "late-binding" - that is a "generic"
reference without specifying a location or version and instead that
info is provided by the client's operating system.

This is the most common way of developing more professional applications
for distribution. You can search this newsgroup for more info on
late-binding and references.

--
'-------------------------------
' John Mishefske
'-------------------------------

[WindAndWaves]

"John Mishefske" <mi****@execpc.com> wrote in message
news:10*************@corp.supernews.com...

WindAndWaves wrote:

"Jack MacDonald" <ja**************@telus.net> wrote in message
news:36********************************@4ax.com...

You should include only the references that are necessary for your
application. If you distribute an application to a machine that does
not have the reference installed, then your application will fail.

Thank you for your answer. I have some more questions:

Is there a way to 'attach' the libraries when distributing a database?

The answer is it depends. If the reference is to code you created and
that you intend to provide and register with the operating system then
perhaps yes but if it is software (like Outlook or Office) that the
customer installs then no. (That's a general answer and exceptions
exist).

References allows VBA to work with software (code) that is not part of
Access. But there are licensing issues; you can't distribute Office
with your application - you can provide the reference that would allow
VBA to work with it.

But that software may not be installed where the reference expects it
or it may not be version you have on your development PC.

You can avoid these problems using "late-binding" - that is a "generic"
reference without specifying a location or version and instead that
info is provided by the client's operating system.

This is the most common way of developing more professional applications
for distribution. You can search this newsgroup for more info on
late-binding and references.

--
'-------------------------------
' John Mishefske
'-------------------------------

Thanks John, I will do some research on late binding.

Kind regards
- Nicolaas

[Tony Toews]

"WindAndWaves" <ac****@ngaru.com> wrote:

Thanks John, I will do some research on late binding.

Standard blurb follows.

Late binding means you can safely remove the reference and only have an error when
the app executes lines of code in question. Rather than erroring out while starting
up the app and not allowing the users in the app at all. Or when hitting a mid, left
or trim function call.

You'll want to install the reference if you are programming or debugging and want to
use the object intellisense while in the VBA editor. Then,. once your app is
running smoothly, remove the reference and setup the late binding statements.

Sample code:
' Declare an object variable to hold the object
' reference. Dim as Object causes late binding.
Dim objWordDoc As Object
Set objWordDoc = CreateObject(" Word.Document")

For more information including additional text and some detailed links see the "Late
Binding in Microsoft Access" page at http://www.granite.ab.ca/access/latebinding.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Tony Toews]

"WindAndWaves" <ac****@ngaru.com> wrote:

So then it really would be best to ditch all the references. Oh well. I
will do my best to get rid of as many as possible in my application.

at the moment, I use:

visual basic for applications
MS Access 11.0 object lib.
Ole automation
MS DAO 3.6
MS ActiveX Data objects 2.5 Library
MS office 11.0 object lib
MS shell controls and automation
MS outlook 11.0 object lib

Access 11.0 object lib implies A2003. I'd suggest deleting any references not on
the below list one at a time and compiling to see if you have any problems in your
code.

The Access 2003 default references when the MDB is in A2000 format are
Visual Basic for Applications
Microsoft Access 11.0 Object Library
OLE Automation
Microsoft DAO 3.6 Object Library
Microsoft ActiveX Data Objects 2.1 Library

The Access 2003 default references when the MDB is in A2002/A2003 format are
Visual Basic for Applications
Microsoft Access 11.0 Object Library
OLE Automation
Microsoft DAO 3.6 Object Library
Microsoft ActiveX Data Objects 2.5 Library

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm