Most people tell me I only need 3 references. It seems
that many of my problems are related to references. I
don't know what a reference is, quite frankly. I wish
that, instead of about 200 references in the list, there
were only those three I need. Many questions come to
mind:
1) How do the references make their way into the list?
2) Must the 197 references in A97 that are unused be
deleted? Or must they remain in the list.
3) May the files comprising these references be used
by something other than Access (in which case,
deleting them might 'break' something else)?
24  2777 
"MLH" <CR**@NorthState.net> wrote in message
news:hc********************************@4ax.com... Most people tell me I only need 3 references. It seems
that many of my problems are related to references. I
don't know what a reference is, quite frankly. I wish
that, instead of about 200 references in the list, there
were only those three I need. Many questions come to
mind:
1) How do the references make their way into the list?
2) Must the 197 references in A97 that are unused be
deleted? Or must they remain in the list.
3) May the files comprising these references be used
by something other than Access (in which case,
deleting them might 'break' something else)?
The references that you see on the list are library files (usually dll's)
that have been registered on your system. Usually happens during
installations. A large percentage of them are from installing Office. And
yes, deleting them could break something else.
Look at the bright side. At least they sort the checked ones to the top.
Imagine if you had to search the entire list to figure out which ones were
selected.
That's a good point. I think it unfortunate that 3rd party s'ware
is able to manipulate the settings during their installation - IE,
removing the checkmark from certain references, adding new
references and checking them - that sort of thing.
Is there a place where I can go view a detailed list of references
that are useful in Access 97 and what they do? And, just as important,
known bugs?
Look at the bright side. At least they sort the checked ones to the top.
Imagine if you had to search the entire list to figure out which ones were
selected.
MLH wrote: That's a good point. I think it unfortunate that 3rd party s'ware
is able to manipulate the settings during their installation - IE,
removing the checkmark from certain references, adding new
references and checking them - that sort of thing.
I don't know of any cases of this. References are checked in your file because
YOU did something to make them be checked. Installing software can mess you up
by changing the version of a reference you are using and it can add more
UN-checked choices to the list, but it will not add checked choices or remove
them.
Is there a place where I can go view a detailed list of references
that are useful in Access 97 and what they do? And, just as important,
known bugs?
Open a new blank file and you will see exactly three checked default references
(Access 97). Those are the only ones you need to ever have checked. Any other
external libraries should be used by late binding which requires no reference.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
MLH <CR**@NorthState.net> wrote in
news:qk********************************@4ax.com: That's a good point. I think it unfortunate that 3rd party s'ware
is able to manipulate the settings during their installation - IE,
removing the checkmark from certain references, adding new
references and checking them - that sort of thing.
Eh? What are you talking about? No 3rd-party software changes
references that have been created in an existing MDB file. All
software installers can do is change the list of resources
registered with COM that can be referenced by an MDB. Now, I guess
it's possible that a program could unregister and uninstall a COM
component that you're using in an MDB, but you haven't actually
identified any that this would be likely for.
The best way to avoid problems with references is to cut down on the
number of outside dependencies in your application, and when you do
need to use COM components that aren't part of Access, then you
should use late binding instead of early binding. That is, you
instantiate an object variable of the appropriate type at runtime in
your code rather than creating a reference to the external library.
The only likely way that you'd get the situation where you'd have a
A97 file with ADO 2.1 as a reference but no DAO 3.51 is if the A97
file originated as an Access 2000 or later file. Microsoft stupidly
set up A2K by default to create new databases with an ADO reference
and no DAO reference, so an MDB created in A2K that was then
converted to A97 would lack the necessary DAO reference (though if
your A2K file starts with a DAO 3.6 reference, the conversion is
smart enough to change it to a DAO 3.51 reference).
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Rick Brandt wrote: MLH wrote:
That's a good point. I think it unfortunate that 3rd party s'ware
is able to manipulate the settings during their installation - IE,
removing the checkmark from certain references, adding new
references and checking them - that sort of thing.
Windows installers (MSI, InstallShield, WISE, InnoSetup, etc) can
register DLLs. The list of libraries is simply the list of all the DLLs
on your computer that VBA can conceivably use.
I don't know of any cases of this. References are checked in your file because
YOU did something to make them be checked. Installing software can mess you up
by changing the version of a reference you are using and it can add more
UN-checked choices to the list, but it will not add checked choices or remove
them.
For a VBA project to compile with early binding, the library has to be
referenced. There probably is a way via the Win32 API to do it, or
change the registry to make it so, too.
Is there a place where I can go view a detailed list of references
that are useful in Access 97 and what they do? And, just as important,
known bugs?
Probably not. There are all sorts of libraries that are exposed, but
some of them are very likely to say something like, "this product is not
licensed for this use" or something. For example, the oldish computer
game, "Command and Conquer: Tiberian Sun", exposed a .TLB...
Open a new blank file and you will see exactly three checked default references
(Access 97). Those are the only ones you need to ever have checked. Any other
external libraries should be used by late binding which requires no reference.
In past experimentation in Access 97 and 2000, it's not possible to
programmatically set up references if you want to use the newly
referenced library in the same VBA project space, even though there are
a couple of functions that support it.
The main reason is that your code won't "compile", and it'll barf when
you try to run it with the library initially unregistered, even though
your code very clearly does try to set up a reference programmatically
before trying to use the library's functions.
Besides, late binding is of much lower performance than early binding,
although it is more generic. Also, the Object Browser only works with
referenced libraries...
David W. Fenton wrote: MLH <CR**@NorthState.net> wrote in
news:qk********************************@4ax.com:
That's a good point. I think it unfortunate that 3rd party s'ware
is able to manipulate the settings during their installation - IE,
removing the checkmark from certain references, adding new
references and checking them - that sort of thing.
Eh? What are you talking about? No 3rd-party software changes
references that have been created in an existing MDB file. All
software installers can do is change the list of resources
registered with COM that can be referenced by an MDB. Now, I guess
it's possible that a program could unregister and uninstall a COM
component that you're using in an MDB, but you haven't actually
identified any that this would be likely for.
At least in A97, it's possible to unreference a library programmatically
in VBA...
The best way to avoid problems with references is to cut down on the
number of outside dependencies in your application, and when you do
need to use COM components that aren't part of Access, then you
should use late binding instead of early binding. That is, you
instantiate an object variable of the appropriate type at runtime in
your code rather than creating a reference to the external library.
Yes, but the best way to develop the code first is to use early binding.
the VBA IDE gets and provides no help if the library is not referenced...
The only likely way that you'd get the situation where you'd have a
A97 file with ADO 2.1 as a reference but no DAO 3.51 is if the A97
file originated as an Access 2000 or later file. Microsoft stupidly
set up A2K by default to create new databases with an ADO reference
and no DAO reference, so an MDB created in A2K that was then
converted to A97 would lack the necessary DAO reference (though if
your A2K file starts with a DAO 3.6 reference, the conversion is
smart enough to change it to a DAO 3.51 reference).
MLH wrote: Most people tell me I only need 3 references. It seems
that many of my problems are related to references. I
don't know what a reference is, quite frankly. I wish
that, instead of about 200 references in the list, there
were only those three I need. Many questions come to
mind:
1) How do the references make their way into the list?
2) Must the 197 references in A97 that are unused be
deleted? Or must they remain in the list.
They're "deleted" when the DLL is unregistered via regsvr32 /u
3) May the files comprising these references be used
by something other than Access (in which case,
deleting them might 'break' something else)?
Sure. But some of them are smart enough to only be used with the product
they're associated with...
Here's some code for y'all (you can add your own error checking):
Option Compare Database
Public Sub AddAReference()
Dim rr As Access.References
'if you know the path to the DLL, then do it thusly:
'rr.AddFromFile "C:\WinNT\System32\dao360.dll"
'because your system isn't like mine, and VBA doesn't have
'a set of global quasiconstants to reference common system directories
'like %PROGRAMDIR%, %SYSTEMDIR%, %WINDOWSDIR%, %COMMONFILESDIR%,
'etc...then...I'll do it like this:
rr.AddFromGuid ("00025E01-0000-0000-C000-000000000046") 'DAO360.dll
' (a way around this is to add the VBScript library as a reference,
' and use the wsh object to get the values. Or, look them up in the
' Registry with more API functions...)
End Sub
Public Sub RemoveAReference()
Dim rr As Access.References
Dim r As Access.Reference
Set rr = Access.References
Set r = Access.References!DAO
rr.Remove r
End Sub
Public Sub EnumReferences()
Dim r As Access.Reference
'VBA {000204EF-0000-0000-C000-000000000046}
' D:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL
'Access {4AFFC9A0-5F99-101B-AF4E-00AA003F0F07}
' D:\Program Files\Microsoft Office\Office\MSACC9.OLB
'stdole {00020430-0000-0000-C000-000000000046}
' D:\WINNT\System32\StdOle2.Tlb
'ADODB {00000201-0000-0010-8000-00AA006D2EA4}
' D:\Program Files\Common Files\System\ADO\msado21.tlb
'-->DAO {00025E01-0000-0000-C000-000000000046}
'D:\Progra~1\Common~1\Micros~1\dao\dao360.dll
For Each r In Access.References
Debug.Print r.Name, r.Guid, r.FullPath
Next r
End Sub
corey lawson wrote: Rick Brandt wrote: I don't know of any cases of this. References are checked in your
file because YOU did something to make them be checked. Installing software
can mess you up by changing the version of a
reference you are using and it can add more UN-checked choices to
the list, but it will not add checked choices or remove them.
For a VBA project to compile with early binding, the library has to be
referenced. There probably is a way via the Win32 API to do it, or
change the registry to make it so, too.
Yes and my point was to NOT use early binding.
Open a new blank file and you will see exactly three checked
default references (Access 97). Those are the only ones you need
to ever have checked. Any other external libraries should be used
by late binding which requires no reference.
In past experimentation in Access 97 and 2000, it's not possible to
programmatically set up references if you want to use the newly
referenced library in the same VBA project space, even though there
are a couple of functions that support it.
But you don't need the reference so this is a moot point.
The main reason is that your code won't "compile", and it'll barf when
you try to run it with the library initially unregistered, even though
your code very clearly does try to set up a reference programmatically
before trying to use the library's functions.
Besides, late binding is of much lower performance than early binding,
although it is more generic. Also, the Object Browser only works with
referenced libraries...
This is one of those "theoretical" performance differences. On modern hardware
a user will never notice the difference between early binding and late binding.
Yes if you did some sort of procedure in a 10000 iteration loop and compared the
time early binding would be faster. Typical situations where the app is
referencing a library to send an Email or interact with Word or Excel are not
going to work any better with early binding.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
<snip>
Windows installers (MSI, InstallShield, WISE, InnoSetup, etc) can
register DLLs. The list of libraries is simply the list of all the DLLs
on your computer that VBA can conceivably use.
OK, then. That must-a-been what happened, as the installation was
an installshield-based process. I'm certain I did not check the new
references myself. I found them after-the-fact.
I don't know of any cases of this. References are checked in your file because
YOU did something to make them be checked. Installing software can mess you up
by changing the version of a reference you are using and it can add more
UN-checked choices to the list, but it will not add checked choices or remove
them.
For a VBA project to compile with early binding, the library has to be
referenced. There probably is a way via the Win32 API to do it, or
change the registry to make it so, too.
The concept of late and early binding is new to me. I don't know what
it means or implies. I'm going to put in some book time. Do you have a
favorite place you'd recommend a novice to go read all about it?
Is there a place where I can go view a detailed list of references
that are useful in Access 97 and what they do? And, just as important,
known bugs?
Probably not. There are all sorts of libraries that are exposed, but
some of them are very likely to say something like, "this product is not
licensed for this use" or something. For example, the oldish computer
game, "Command and Conquer: Tiberian Sun", exposed a .TLB...
OK.
Open a new blank file and you will see exactly three checked default references
(Access 97). Those are the only ones you need to ever have checked. Any other
external libraries should be used by late binding which requires no reference.
I'm glad you made this point. I have 4. The 4th is the MS Calendar
control. I really would like to rearrange my coding, adopting the late
binding technique. Of course, since I don't know what that means
yet, I have no idea how to start. Shouldn't be too difficult??? What
I'm guessing is that "early binding" is when you have a reference to
the dll and "late binding" is when you don't have a reference set up
for the dll but you use it via a Declare statement in a module some-
where. Is that anywhere close to what is meant???
In past experimentation in Access 97 and 2000, it's not possible to
programmatically set up references if you want to use the newly
referenced library in the same VBA project space, even though there are
a couple of functions that support it.
The main reason is that your code won't "compile", and it'll barf when
you try to run it with the library initially unregistered, even though
your code very clearly does try to set up a reference programmatically
before trying to use the library's functions.
Besides, late binding is of much lower performance than early binding,
although it is more generic. Also, the Object Browser only works with
referenced libraries...
Probably won't notice (and I'm just guessing here) the perf reduction
in the little calendar thing, huh? I only have it on a few forms. Eh? What are you talking about? No 3rd-party software changes
references that have been created in an existing MDB file. All
software installers can do is change the list of resources
registered with COM that can be referenced by an MDB. Now, I guess
it's possible that a program could unregister and uninstall a COM
component that you're using in an MDB, but you haven't actually
identified any that this would be likely for.
The best way to avoid problems with references is to cut down on the
number of outside dependencies in your application, and when you do
need to use COM components that aren't part of Access, then you
should use late binding instead of early binding. That is, you
instantiate an object variable of the appropriate type at runtime in
your code rather than creating a reference to the external library.
The only likely way that you'd get the situation where you'd have a
A97 file with ADO 2.1 as a reference but no DAO 3.51 is if the A97
file originated as an Access 2000 or later file. Microsoft stupidly
set up A2K by default to create new databases with an ADO reference
and no DAO reference, so an MDB created in A2K that was then
converted to A97 would lack the necessary DAO reference (though if
your A2K file starts with a DAO 3.6 reference, the conversion is
smart enough to change it to a DAO 3.51 reference).
Eureka! That's it. You're right - that's what happened. I got the mdb
as a sample mdb demonstrating the use of an OCX control. The mdb
was originally an A2K product and the guy sent it through a time-
tunnel back to A97 as a favor to me. That seems to follow along with
what you're saying.
Now let me get this straight, once and for all. Say I have 10 mdb's
all created with A97. I open number one and check 4 or 5 references,
then exit SAVING them permanently in number one MDB file. I can
rest assured that, when opening the other 9 - none of them will have
the additional chosen references that I added to number one - that is,
of course, assuming they only had the BASIC-3 to start with. Am I on
track with that? Or, am I completely off base?
MLH wrote: Now let me get this straight, once and for all. Say I have 10 mdb's
all created with A97. I open number one and check 4 or 5 references,
then exit SAVING them permanently in number one MDB file. I can
rest assured that, when opening the other 9 - none of them will have
the additional chosen references that I added to number one - that is,
of course, assuming they only had the BASIC-3 to start with. Am I on
track with that? Or, am I completely off base?
Yes references are per-file.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
On Fri, 21 Oct 2005 21:26:17 -0700, corey lawson
<co**********@ayeteatea.net> wrote: MLH wrote:
Most people tell me I only need 3 references. It seems
that many of my problems are related to references. I
don't know what a reference is, quite frankly. I wish
that, instead of about 200 references in the list, there
were only those three I need. Many questions come to
mind:
1) How do the references make their way into the list?
2) Must the 197 references in A97 that are unused be
deleted? Or must they remain in the list.
They're "deleted" when the DLL is unregistered via regsvr32 /u
Thx. That may come in handy some time. I'll be careful, though.
3) May the files comprising these references be used
by something other than Access (in which case,
deleting them might 'break' something else)?
Sure. But some of them are smart enough to only be used with the product
they're associated with...
I hope there's a lot of them around.
<snip'd the code sequence that I'm not smart enough to comment on>
(although it does look quite interesting)
Thx, Rick. That takes a load off.
Yes references are per-file.
MLH wrote: The concept of late and early binding is new to me. I don't know what
it means or implies. I'm going to put in some book time. Do you have a
favorite place you'd recommend a novice to go read all about it?
Here is how I think of it (I'm sure that conceptually parts of this are wrong).
When you add a reference to Word and then have code like...
Dim VariableName as Word.Application
Set VariableName = New Word.Application
You are essentially instructing Windows to "Make me an object of this type found
in this specific registered COM library". This is early binding (because you
earlier created a reference to the Word library) so Windows knows exactly where
to get this object. The problem is if Windows can't find that specific library
because it is either not installed at all, not installed properly, or is the
wrong version than expected.
When you use late binding...
Dim VariableName as Object
Set VariableName = CreateObject("Word.Application")
You are now essentially asking Windows "I need a Word Application object. Use
whatever COM library is appropriate". So Windows has to use the registry to
determine if it has a library registered capable of creating that type of object
and then will do so if it finds one. This step is why late binding is a bit
slower, but on modern hardware this delay is miniscule. This is also why late
binding is mostly version independent. As long as there is a registered library
capable of creating the necessary object then the code works.
Early binding is easier to write code for because you can catch mistakes at
compile time and get to use intellisense. So most developers set the reference
and use early binding to get the code working and then remove the reference and
change the few lines of code necessary to make late binding work.
I typically have both the early and late binding lines in my code and just
comment out the ones for early binding once everything is working. If I have a
problem to fix later or a new feature to add I can easily go back to early
binding if I think it will be faster to get the new code working and then change
back to late binding when finished.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Well, that makes perfect sense, Rick. Thx a lot.
And I like your approach in the utilization of both.
It does make sense to use one while developing
- taking full advantage of intellisense and the other
method when rolling it out.
The first thing I'm gonna try this on is the Calendar
control by Microsoft that I'm using. I like the control.
On SOME machines I rolled the app out on, I remember
having to take extra steps before the the thing worked
on those target machines. I imagine the reason was
that I was employing early binding in my app when
rolling it out.
MLH wrote: Well, that makes perfect sense, Rick. Thx a lot.
And I like your approach in the utilization of both.
It does make sense to use one while developing
- taking full advantage of intellisense and the other
method when rolling it out.
The first thing I'm gonna try this on is the Calendar
control by Microsoft that I'm using. I like the control.
On SOME machines I rolled the app out on, I remember
having to take extra steps before the the thing worked
on those target machines. I imagine the reason was
that I was employing early binding in my app when
rolling it out.
I don't think you can go to late binding for a reference that is there
for a Control. Since the Calander Control is present on a Form, the
binding needs to be early. This is one of the reasons that some
developers have written their own Calanders.
--
Bri
Well, that settles that then. Thx.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I don't think you can go to late binding for a reference that is there
for a Control. Since the Calander Control is present on a Form, the
binding needs to be early. This is one of the reasons that some
developers have written their own Calanders.
Bri wrote: MLH wrote: Well, that makes perfect sense, Rick. Thx a lot.
And I like your approach in the utilization of both.
It does make sense to use one while developing
- taking full advantage of intellisense and the other
method when rolling it out.
The first thing I'm gonna try this on is the Calendar
control by Microsoft that I'm using. I like the control.
On SOME machines I rolled the app out on, I remember
having to take extra steps before the the thing worked
on those target machines. I imagine the reason was
that I was employing early binding in my app when
rolling it out.
I don't think you can go to late binding for a reference that is there
for a Control. Since the Calander Control is present on a Form, the
binding needs to be early. This is one of the reasons that some
developers have written their own Calanders.
Yeah OCX controls are different, but this is what I have found with two that I
am using. I add the control to a form and a reference is automatically added.
Later though I can remove that reference and the control still works.
I do this with the MS Outline control and with a Web Browser control. Both work
just fine without the reference checked.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
corey lawson <co**********@ayeteatea.net> wrote in
news:11*************@corp.supernews.com: Besides, late binding is of much lower performance than early
binding, although it is more generic.
This is not an issue if you use a global variable to initialize your
top-level application object within any one Access session. You'd
only have a speed hit on the first initialization.
Of course, it's not always possible to do it that way.
But other than Outlook, I've never seen any late binding that was
slow enough to justify a switch to early binding.
That was one among the many reasons that I determined that
automating Outlook was really not a viable option.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Rick Brandt wrote: Bri wrote:
MLH wrote:
Well, that makes perfect sense, Rick. Thx a lot.
And I like your approach in the utilization of both.
It does make sense to use one while developing
- taking full advantage of intellisense and the other
method when rolling it out.
The first thing I'm gonna try this on is the Calendar
control by Microsoft that I'm using. I like the control.
On SOME machines I rolled the app out on, I remember
having to take extra steps before the the thing worked
on those target machines. I imagine the reason was
that I was employing early binding in my app when
rolling it out.
I don't think you can go to late binding for a reference that is there
for a Control. Since the Calander Control is present on a Form, the
binding needs to be early. This is one of the reasons that some
developers have written their own Calanders.
Yeah OCX controls are different, but this is what I have found with two that I
am using. I add the control to a form and a reference is automatically added.
Later though I can remove that reference and the control still works.
I do this with the MS Outline control and with a Web Browser control. Both work
just fine without the reference checked.
I never thought to even try that. I wonder though if the control is
still on a form if there is an implied reference that is still there?
The test would be to move the app to a machine with a different version
of the control. If it works, then you've late bound the control, if it
fails then there is an implied reference in there somewhere.
--
Bri
"Bri" <no*@here.com> wrote in message
news:LMw6f.257269$oW2.49868@pd7tw1no...
Rick Brandt wrote: Bri wrote:
MLH wrote:
Well, that makes perfect sense, Rick. Thx a lot.
And I like your approach in the utilization of both.
It does make sense to use one while developing
- taking full advantage of intellisense and the other
method when rolling it out.
The first thing I'm gonna try this on is the Calendar
control by Microsoft that I'm using. I like the control.
On SOME machines I rolled the app out on, I remember
having to take extra steps before the the thing worked
on those target machines. I imagine the reason was
that I was employing early binding in my app when
rolling it out.
I don't think you can go to late binding for a reference that is there
for a Control. Since the Calander Control is present on a Form, the
binding needs to be early. This is one of the reasons that some
developers have written their own Calanders.
Yeah OCX controls are different, but this is what I have found with two
that I am using. I add the control to a form and a reference is automatically
added. Later though I can remove that reference and the control still works.
I do this with the MS Outline control and with a Web Browser control.
Both work just fine without the reference checked.
I never thought to even try that. I wonder though if the control is
still on a form if there is an implied reference that is still there?
The test would be to move the app to a machine with a different version
of the control. If it works, then you've late bound the control, if it
fails then there is an implied reference in there somewhere.
--
Bri
I don't believe that there would be an implied reference. I think what you
want to do is clear the reference then compile to see if it is needed or
not. Yeah OCX controls are different, but this is what I have found with two that I
am using. I add the control to a form and a reference is automatically added.
Later though I can remove that reference and the control still works.
YES! I verified that same thing. I have no idea how to explain that. I
cannot even FIND the reference in the list now - and it still works.
So I couldn't check it now if I wanted to - unless I ran the setup.exe
that accompanied the control again.
I do this with the MS Outline control and with a Web Browser control. Both work
just fine without the reference checked.
Randy Harris wrote: "Bri" <no*@here.com> wrote in message I never thought to even try that. I wonder though if the control is
still on a form if there is an implied reference that is still
there? The test would be to move the app to a machine with a
different version of the control. If it works, then you've late
bound the control, if it fails then there is an implied reference
in there somewhere.
-- Bri
I don't believe that there would be an implied reference. I think
what you want to do is clear the reference then compile to see if it
is needed or not.
What I'm thinking is that the Control has the reference, not Access.
That would mean that if you moved the App to a PC with a different
version of the control or without the OCX Registered that the Control
will fail to work. This means that you still have to be sure that your
version of the Control gets installed with your app. Compile will have
nothing to do with it as the reference is in the Control and it will
only fail at runtime if the Control can't find its reference.
If you were truely free of the reference, then the app would use
whatever version is available. I'm guessing that this isn't what happens.
--
Bri
Bri wrote: What I'm thinking is that the Control has the reference, not Access.
That would mean that if you moved the App to a PC with a different
version of the control or without the OCX Registered that the Control
will fail to work. This means that you still have to be sure that your
version of the Control gets installed with your app. Compile will have
nothing to do with it as the reference is in the Control and it will
only fail at runtime if the Control can't find its reference.
If you were truely free of the reference, then the app would use
whatever version is available. I'm guessing that this isn't what
happens.
That is my impression. You clearly still need the control installed and
registered and in the proper version. It is "sort of" like late binding
though in the respect that if the control is not registered properly all
that fails is the control. It does not cause (AFAIK) the built in function
failures typically seen with a broken reference.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: JustMe |
last post by:
I don't know if this has anything to do with AccessXP running on Terminal
Services with Access97/2000 also installed, but here is one example of a
query that does not work any longer:
SELECT...
|
by: Peter Mather |
last post by:
Hi,
I have struck problems when trying to convert an Access97 database to
Access 2000.
I get a compile Error when I start the database in Access 2000.. The
message is Can't find project or...
|
by: Barry Young |
last post by:
I have Access 2000 installed on a machine and I create the MDE just fine.
When I copy the MDE file over to another machine that has Access 2000
installed, the references are hosed and I get unable...
|
by: WindAndWaves |
last post by:
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...
|
by: SAM |
last post by:
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...
|
by: Lauren Wilson |
last post by:
Hello good folks!
It is WAY past time for me to figure out how to check for the
existence of all referenced libraries on application startup and
provide feedback to the user if they are not.
...
|
by: prn |
last post by:
Hi folks,
I'm relatively new to Access, but I seem to have drawn the short straw, so I have the assignment for my workplace of looking for problems/inconsistencies in migrating applications to...
|
by: mnjkahn via AccessMonster.com |
last post by:
I'm running Access 2003, modifying a query that has over 45 fields. When I
right click on the field name in Query Design View, and then click Build,
Access crashes before the Build window...
|
by: nico5038 |
last post by:
Access 2007 Linkedtable manager refuses to relink tables having a field with the "Attachment" datatype.
Problem:
When placing a split database in another folder, the Linked table manager should...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
