Determine References Used

[alex]

Determine References Used

Hello,

Using Access ’03…

I just rolled out an mde to a test group of users…

Several were successful, but I had one crash due to a DAO reference
not established. The development PC used 3.6 and user’s PC had no DAO
reference checked and only DAO 2.something available.

Being a novice programmer, I get a lot of help from groups like this;
while I strive to know what the code does, I often am unsure about the
references used with the code.

I found some helpful information from Doug’s site here:
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

I’m inquiring if it’s possible to run code to determine the references
needed to run a particular application? The html doc above has this
code:

Dim refCurr As Reference

For Each refCurr In Application.References
Debug.Print refCurr.Name & ": " & refCurr.FullPath
Next

Which says is used to determine all of the required references, but
only seems to list the checked (Tools > References) references and not
the ones required by any/all of the modules in the current
application; i.e., what references are required for the code to work?
I’m guessing that a simple mde/mdb with no code does not require a
reference to DAO or ADO.

For example, if you were going to roll out an mde to many workstations
and you knew there were some without the DAO reference, you could
modify (or never start) your code so it did not require such a
reference (as long as you were able to of course).

Any advice on this issue would be greatly appreciated,
alex

 

[Douglas J. Steele]

Remove as many references as you can (Access won't let you remove them all)
and Compile. If you need a reference, you'll get an compilation error.

Add your references back one by one to get rid of the compilation error.
(i.e. Add reference A and recompile. If the same compilation error is
highlighted, remove reference B and recompile. Once the first compilation
error has been corrected, continue until there are no more compilation
errors)


--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


Determine References Used

Hello,

Using Access ’03…

I just rolled out an mde to a test group of users…

Several were successful, but I had one crash due to a DAO reference
not established. The development PC used 3.6 and user’s PC had no DAO
reference checked and only DAO 2.something available.

Being a novice programmer, I get a lot of help from groups like this;
while I strive to know what the code does, I often am unsure about the
references used with the code.

I found some helpful information from Doug’s site here:
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

I’m inquiring if it’s possible to run code to determine the references
needed to run a particular application? The html doc above has this
code:

Dim refCurr As Reference

For Each refCurr In Application.References
Debug.Print refCurr.Name & ": " & refCurr.FullPath
Next

Which says is used to determine all of the required references, but
only seems to list the checked (Tools > References) references and not
the ones required by any/all of the modules in the current
application; i.e., what references are required for the code to work?
I’m guessing that a simple mde/mdb with no code does not require a
reference to DAO or ADO.

For example, if you were going to roll out an mde to many workstations
and you knew there were some without the DAO reference, you could
modify (or never start) your code so it did not require such a
reference (as long as you were able to of course).

Any advice on this issue would be greatly appreciated,
alex

 

[alex]

Remove as many references as you can (Access won't let you remove them all)
and Compile. If you need a reference, you'll get an compilation error.

Add your references back one by one to get rid of the compilation error.
(i.e. Add reference A and recompile. If the same compilation error is
highlighted, remove reference B and recompile. Once the first compilation
error has been corrected, continue until there are no more compilation
errors)

--
Doug Steele, Microsoft Access MVPhttp://I.Am/DougSteele
(no private e-mails, please)


Determine References Used

Hello,

Using Access ’03…

I just rolled out an mde to a test group of users…

Several were successful, but I had one crash due to a DAO reference
not established.  The development PC used 3.6 and user’s PC had no DAO
reference checked and only DAO 2.something available.

Being a novice programmer, I get a lot of help from groups like this;
while I strive to know what the code does, I often am unsure about the
references used with the code.

I found some helpful information from Doug’s site here:http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

I’m inquiring if it’s possible to run code to determine the references
needed to run a particular application?  The html doc above has this
code:

Dim refCurr As Reference

  For Each refCurr In Application.References
    Debug.Print refCurr.Name & ": " & refCurr.FullPath
  Next

Which says is used to determine all of the required references, but
only seems to list the checked (Tools > References) references and not
the ones required by any/all of the modules in the current
application; i.e., what references are required for the code to work?
I’m guessing that a simple mde/mdb with no code does not require a
reference to DAO or ADO.

For example, if you were going to roll out an mde to many workstations
and you knew there were some without the DAO reference, you could
modify (or never start) your code so it did not require such a
reference (as long as you were able to of course).

Any advice on this issue would be greatly appreciated,
alex

Thanks Doug for responding...I'm glad you did!
That makes sense and I'll do just that.

Also (if you read this again) what do you think about running the code
mentioned above to check for a DAO reference at startup (on the user's
PC). If it exists, do nothing, if it does not exist then provide an
error message stating such and then shut down the application (until
it can be resolved on the user's PC).

This is assuming that the DAO reference is required and also assuming
that the versions will be same (on the developer and user's PC)...just
a thought.
alex

 

[Tony Toews [MVP]]

Several were successful, but I had one crash due to a DAO reference
not established. The development PC used 3.6 and user’s PC had no DAO
reference checked and only DAO 2.something available.

That's highly unusual as DAO 3.6/Jet 4.0 is installed on Windows 2000,
XP, Vista and Windows 7. Chances are the DAO DLL needs registering

For example regsvr32 "C:\Program Files\Common Files\Microsoft
Shared\DAO\DAO360.DLL"

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[alex]

That's highly unusual as DAO 3.6/Jet 4.0 is installed on Windows 2000,
XP, Vista and Windows 7.   Chances are the DAO DLL needs registering

For example regsvr32 "C:\Program Files\Common Files\Microsoft
Shared\DAO\DAO360.DLL"

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
  updated seehttp://www.autofeupdater.com/
Granite Fleet Managerhttp://www.granitefleet.com/

Hi Tony,

We've had this problem before (I have to check with our IT dept to
determine what the fix has been). I'd like to test for it and stop
any further execution on the user's PC until (as you mentioned above)
the DAO reference can be registered. I'm not sure what the best
course of action is...write code with no DAO reference or check for
the DAO reference on the user's PC and if it doesn't exit stop
execution.
alex

 

[Douglas J. Steele]

One of the references I had in the article of mine that you cited is a link
to MichKa's "How to guarantee that references will work in your
applications" at http://www.trigeminal.com/usenet/usenet026.asp

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)



Thanks Doug for responding...I'm glad you did!
That makes sense and I'll do just that.

Also (if you read this again) what do you think about running the code
mentioned above to check for a DAO reference at startup (on the user's
PC). If it exists, do nothing, if it does not exist then provide an
error message stating such and then shut down the application (until
it can be resolved on the user's PC).

This is assuming that the DAO reference is required and also assuming
that the versions will be same (on the developer and user's PC)...just
a thought.
alex

 

[alex]

One of the references I had in the article of mine that you cited is a link
to MichKa's "How to guarantee that references will work in your
applications" athttp://www.trigeminal.com/usenet/usenet026.asp

--
Doug Steele, Microsoft Access MVPhttp://I.Am/DougSteele
(no e-mails, please!)


Thanks Doug for responding...I'm glad you did!
That makes sense and I'll do just that.

Also (if you read this again) what do you think about running the code
mentioned above to check for a DAO reference at startup (on the user's
PC).  If it exists, do nothing, if it does not exist then provide an
error message stating such and then shut down the application (until
it can be resolved on the user's PC).

This is assuming that the DAO reference is required and also assuming
that the versions will be same (on the developer and user's PC)...just
a thought.
alex

Thanks Doug; I'll look at it again...I don't remember anything about
code to check the user's PC.
alex

 

[Arvin Meyer [MVP]]

Thanks Doug; I'll look at it again...I don't remember anything about
code to check the user's PC.

Here's some code to give you a list of references:

http://www.datastrat.com/Code/GetReferences.txt

 

[alex]

Thanks Doug; I'll look at it again...I don't remember anything about
code to check the user's PC.

Here's some code to give you a list of references:

http://www.datastrat.com/Code/GetReferences.txt

Thanks Arvin; I'll take a look at it.
Appreciate the help,
alex

 

[David W. Fenton]

Remove as many references as you can (Access won't let you remove
them all) and Compile. If you need a reference, you'll get an
compilation error.

Add your references back one by one to get rid of the compilation
error. (i.e. Add reference A and recompile. If the same
compilation error is highlighted, remove reference B and
recompile. Once the first compilation error has been corrected,
continue until there are no more compilation errors)

Why not remove them one at a time, instead, compiling with each one?

Also, it's a good idea to make sure your code compiles *before* you
start removing references, since you could incorrectly think that
the reference removal was the cause of the compile error.

 

[David W. Fenton]

m:

write code with no DAO reference or check for
the DAO reference on the user's PC

I would say that if the DAO reference is broken, the Access app is
not usable at all. DAO is so central to Access that without a
working DAO reference, you should just give up and figure out how to
fix the PC, rather than trying to pre-emptively program around it.

 

[Douglas J. Steele]

Why not remove them one at a time, instead, compiling with each one?

Because I'd rather they start lean and mean instead of just hoping they end
up that way! However, your approach would be simpler, since it removes the
need to write down what references you had at the beginning.

Also, it's a good idea to make sure your code compiles *before* you
start removing references, since you could incorrectly think that
the reference removal was the cause of the compile error.

Excellent suggestion. Another point is to ensure that Option Explicit is in
effect.
http://www.access.qbuilt.com/html/gem_tips.html#VBEOptions

 

[Arvin Meyer [MVP]]

m:


I would say that if the DAO reference is broken, the Access app is
not usable at all. DAO is so central to Access that without a
working DAO reference, you should just give up and figure out how to
fix the PC, rather than trying to pre-emptively program around it.

Unless, of course, one is using ADO. A reference to DAO is unnecessary if
one is using ADO. In fact, several versions of Access never set the DAO
reference, but did set the ADO one.

I personally prefer DAO, and always make sure it is installed and properly
registered, and the reference is correct. It is, however, possible not to
use it.

 

[alex]

Unless, of course, one is using ADO. A reference to DAO is unnecessary if
one is using ADO. In fact, several versions of Access never set the DAO
reference, but did set the ADO one.

I personally prefer DAO, and always make sure it is installed and properly
registered, and the reference is correct. It is, however, possible not to
use it.

Again, Thanks guys for the advice.

David,
I was going to ask about the importance of DAO and should I just code
around it. One of the hardest things about learning to write code in
Access is dealing with the multiple references (I say let's have one
and be done with it).

If you read this again (responding to Arvin's response): Can you code
without an ADO AND DAO reference? I.e., why couldn't use just use the
Access Library (provided your application isn't too complicated)?

alex

 

[David W. Fenton]

Unless, of course, one is using ADO.

....one shouldn't.

A reference to DAO is unnecessary if
one is using ADO.

....exclusively, but one shouldn't.

In fact, several versions of Access never set the DAO
reference, but did set the ADO one.

....and that was recognized as a mistake and corrected in later
versions.

I personally prefer DAO, and always make sure it is installed and
properly registered, and the reference is correct. It is, however,
possible not to use it.

....though not advisable when you're using a Jet/ACE data store, or
the recommended method for working with server back ends, i.e., ODBC
(which is managed by Jet/ACE).

 

[David W. Fenton]

:

Can you code
without an ADO AND DAO reference? I.e., why couldn't use just use
the Access Library (provided your application isn't too
complicated)?

Sure. You can use late binding with either. If I were to borrow from
ADO one of the handful of things it does that DAO does not, I'd
definitely use late binding.

But late binding for DAO makes no sense. You don't even need to
utilize the usual CreateObject(), because Application.CurrentDB
provides an interface to all the DAO object model. But you lose
strong data typing for your DAO objects (you have to use generic
object variables or variants), and that's something I don't want to
do. Strong data typing is essential to a bug-free and maintainable
app, and I won't sacrifice it except for outside libraries that are
used only occasionally. For something as central to Access as DAO,
it just makes no sense.

I don't have a single app in production use that has more than the
three base references, i.e., Access, VBA and DAO.

 

[Arvin Meyer [MVP]]

If you read this again (responding to Arvin's response): Can you code
without an ADO AND DAO reference? I.e., why couldn't use just use the
Access Library (provided your application isn't too complicated)?
---------------------------
You need a reference to one or the other if you are going to use anything
worthwhile. You do not need to disambiguate the reference if you only have
one, but I find that it's just as easy to do it right once, so I always use
the complete reference to DAO, like:

Dim db As DAO.Database

I would rather use explicit references and write code that's easy to
understand. After all, I might need to figure out what I did years later.

 

[David W. Fenton]

:

If you read this again (responding to Arvin's response): Can you
code without an ADO AND DAO reference? I.e., why couldn't use
just use the Access Library (provided your application isn't too
complicated)?

Yes, you can. You can use Application.CurrentDb or
CurrentProject.Connection as your gateway to ADO.

But as I said, you don't get strong typing of variables, so I would
say it's completely inadvisable.