469,636 Members | 1,805 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,636 developers. It's quick & easy.

late binding ?

I was reading about late binding, but I'm not completely sure what is to be
done in order to adjust code to late binding...
For example, I'm not sure if this is correct:

early binding:

Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
late binding:
Dim ws as Object
Set ws =CreateObject("DAO.Workspace")
Dim ws as Object
Set db =CreateObject("DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("DAO.Recordset")

VBA help says that class argument inside Create object function has to be in
appname.objecttype format. Does it means that "DAO" should be preceded by
"Access", so the previous code should be like this:

Dim ws as Object
Set ws =CreateObject("Access.DAO.Workspace")
Dim ws as Object
Set db =CreateObject("Access.DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("Access.DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("Access.DAO.Recordset")
?
What exactly I need to change in my code in order to support "late binding"
?
All examples given in VBA help and internet are concerning late binding in
case of calling other Office aplication from Access, but I couldn't find
examples of late binding inside Access itself...so I'm little bit confused.
Is there any Add-in or program, that can change early binding declarations
to late binding declarations through all modules automaticcally ?
Zlatko
Nov 13 '05 #1
9 9869
On Wed, 17 Aug 2005 11:32:08 +0200, "Zlatko Matić"
<zl***********@sb.t-com.hr> wrote:

You are doing it right in the first code block, but if I ever see you
late bind you DAO, you'll get a spanking :-)
DAO has nothing to do with Access perse; it is a standalone object
model to work with a Jet database, that happens to be embraced by
Access.
Use a technique not because you just read about it, but because you
have a need. Typically late binding is used with somewhat obscure
objects that you can't be sure exist on the user's computer, and where
you have the option to "gracefully degrade" your app if the object was
not found. DAO is not such an object, nor could you likely gracefully
degrade your app if it was not found.

-Tom.

I was reading about late binding, but I'm not completely sure what is to be
done in order to adjust code to late binding...
For example, I'm not sure if this is correct:

early binding:

Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
late binding:
Dim ws as Object
Set ws =CreateObject("DAO.Workspace")
Dim ws as Object
Set db =CreateObject("DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("DAO.Recordset")

VBA help says that class argument inside Create object function has to be in
appname.objecttype format. Does it means that "DAO" should be preceded by
"Access", so the previous code should be like this:

Dim ws as Object
Set ws =CreateObject("Access.DAO.Workspace")
Dim ws as Object
Set db =CreateObject("Access.DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("Access.DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("Access.DAO.Recordset")
?
What exactly I need to change in my code in order to support "late binding"
?
All examples given in VBA help and internet are concerning late binding in
case of calling other Office aplication from Access, but I couldn't find
examples of late binding inside Access itself...so I'm little bit confused.
Is there any Add-in or program, that can change early binding declarations
to late binding declarations through all modules automaticcally ?
Zlatko


Nov 13 '05 #2
Hi, Tom!
In fact the only reason why I was looking about late binding is because I
want to distribute .mde to users with different Office versions. I didn't
experience problems with DAO references, but ADO (msado15.dll), by the way.
So, my question could be asked also for ADO objects (connection object,
recordset object, command object...) as well as for DAO or any other
libraries.
I just couldn't find any true example of late binding in Access. Does
anybody use it in real life, after all? Or it is just hipothetical
possibility ?
If it is not common practice, how people solve problems concerning
compatibility on different Office versions ?
It is maybe not a big problem if you distribute .mdb, so every user can
adjust references, but it is not possible in .mde...
How do you solve references problem in .mde ?

Greetings,

Zlatko

"Tom van Stiphout" <no*************@cox.net> je napisao u poruci interesnoj
grupi:gp********************************@4ax.com.. .
On Wed, 17 Aug 2005 11:32:08 +0200, "Zlatko Matić"
<zl***********@sb.t-com.hr> wrote:

You are doing it right in the first code block, but if I ever see you
late bind you DAO, you'll get a spanking :-)
DAO has nothing to do with Access perse; it is a standalone object
model to work with a Jet database, that happens to be embraced by
Access.
Use a technique not because you just read about it, but because you
have a need. Typically late binding is used with somewhat obscure
objects that you can't be sure exist on the user's computer, and where
you have the option to "gracefully degrade" your app if the object was
not found. DAO is not such an object, nor could you likely gracefully
degrade your app if it was not found.

-Tom.

I was reading about late binding, but I'm not completely sure what is to
be
done in order to adjust code to late binding...
For example, I'm not sure if this is correct:

early binding:

Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
late binding:
Dim ws as Object
Set ws =CreateObject("DAO.Workspace")
Dim ws as Object
Set db =CreateObject("DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("DAO.Recordset")

VBA help says that class argument inside Create object function has to be
in
appname.objecttype format. Does it means that "DAO" should be preceded by
"Access", so the previous code should be like this:

Dim ws as Object
Set ws =CreateObject("Access.DAO.Workspace")
Dim ws as Object
Set db =CreateObject("Access.DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("Access.DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("Access.DAO.Recordset")
?
What exactly I need to change in my code in order to support "late
binding"
?
All examples given in VBA help and internet are concerning late binding in
case of calling other Office aplication from Access, but I couldn't find
examples of late binding inside Access itself...so I'm little bit
confused.
Is there any Add-in or program, that can change early binding declarations
to late binding declarations through all modules automaticcally ?
Zlatko

Nov 13 '05 #3
Zlatko Matic wrote:
Hi, Tom!
In fact the only reason why I was looking about late binding is
because I want to distribute .mde to users with different Office
versions. I didn't experience problems with DAO references, but ADO
(msado15.dll), by the way. So, my question could be asked also for
ADO objects (connection object, recordset object, command object...)
as well as for DAO or any other libraries.
I just couldn't find any true example of late binding in Access. Does
anybody use it in real life, after all? Or it is just hipothetical
possibility ?
If it is not common practice, how people solve problems concerning
compatibility on different Office versions ?
It is maybe not a big problem if you distribute .mdb, so every user
can adjust references, but it is not possible in .mde...
How do you solve references problem in .mde ?


I would hazard a guess that for developers that know what there doing that
late binding is overwhelmingly used instead of early binding. I would NEVER
use early binding except in cases where there is absolute control over the
software that is installed (and isn't installed) on the target PCs. Late
binding is just too darned easy to implement to risk any chance of
versioning problems and broken references that early binding inevitably
produces.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #4
On Thu, 18 Aug 2005 21:22:44 +0200, "Zlatko Matic"
<zl***********@sb.t-com.hr> wrote:

I use it quite regularly. For example in an app that uses Msft
MapPoint to draw a map. It's no big deal if you don't have MapPoint
installed; you'll just not have the "View as Map" button.

With regards to Office: let's assume that your app uses Word to
generate some letters, and that the user MUST have Office2000 or
better installed. Then write your code in Access 2000, with Word 2000
reference selected. You write early-binding code. If your app is
installed on a computer with a higher version of Office, the reference
will AUTOMATICALLY be "upgraded" to Word XP, Word 2003, etc. That's
the power of OLE for you.

-Tom.

Hi, Tom!
In fact the only reason why I was looking about late binding is because I
want to distribute .mde to users with different Office versions. I didn't
experience problems with DAO references, but ADO (msado15.dll), by the way.
So, my question could be asked also for ADO objects (connection object,
recordset object, command object...) as well as for DAO or any other
libraries.
I just couldn't find any true example of late binding in Access. Does
anybody use it in real life, after all? Or it is just hipothetical
possibility ?
If it is not common practice, how people solve problems concerning
compatibility on different Office versions ?
It is maybe not a big problem if you distribute .mdb, so every user can
adjust references, but it is not possible in .mde...
How do you solve references problem in .mde ?

Greetings,

Zlatko

"Tom van Stiphout" <no*************@cox.net> je napisao u poruci interesnoj
grupi:gp********************************@4ax.com. ..
On Wed, 17 Aug 2005 11:32:08 +0200, "Zlatko Matić"
<zl***********@sb.t-com.hr> wrote:

You are doing it right in the first code block, but if I ever see you
late bind you DAO, you'll get a spanking :-)
DAO has nothing to do with Access perse; it is a standalone object
model to work with a Jet database, that happens to be embraced by
Access.
Use a technique not because you just read about it, but because you
have a need. Typically late binding is used with somewhat obscure
objects that you can't be sure exist on the user's computer, and where
you have the option to "gracefully degrade" your app if the object was
not found. DAO is not such an object, nor could you likely gracefully
degrade your app if it was not found.

-Tom.

I was reading about late binding, but I'm not completely sure what is to
be
done in order to adjust code to late binding...
For example, I'm not sure if this is correct:

early binding:

Dim ws As DAO.Workspace
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Dim rs As DAO.Recordset
late binding:
Dim ws as Object
Set ws =CreateObject("DAO.Workspace")
Dim ws as Object
Set db =CreateObject("DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("DAO.Recordset")

VBA help says that class argument inside Create object function has to be
in
appname.objecttype format. Does it means that "DAO" should be preceded by
"Access", so the previous code should be like this:

Dim ws as Object
Set ws =CreateObject("Access.DAO.Workspace")
Dim ws as Object
Set db =CreateObject("Access.DAO.Database")
Dim qdf as Object
Set qdf =CreateObject("Access.DAO.QueryDef")
Dim rs as Object
Set rs =CreateObject("Access.DAO.Recordset")
?
What exactly I need to change in my code in order to support "late
binding"
?
All examples given in VBA help and internet are concerning late binding in
case of calling other Office aplication from Access, but I couldn't find
examples of late binding inside Access itself...so I'm little bit
confused.
Is there any Add-in or program, that can change early binding declarations
to late binding declarations through all modules automaticcally ?
Zlatko


Nov 13 '05 #5
Hi, Rick.
So, could you tell me what is wrong with this part of code:

Dim ws As Object
Set ws = CreateObject("DAO.Workspace")
Dim db As Object
Set db = CreateObject("DAO.Database")
Dim qdf As Object
Set qdf = CreateObject("DAO.QueryDef")
Dim qdfSQL As String
Dim rs As Object
Set rs = CreateObject("DAO.Recordset")

On Error GoTo GRESKA

DoCmd.Hourglass True

Set ws = DBEngine(0)
Set db = CurrentDb
.....

When I execute this function, an error apears: "ActiveX component can't
create an object".
I suppose it is something regarding CurrentDb or DBEngine (0) ? How to open
current database using late binding ?
If you regulary use late binding yould you give me some example of DAO lata
binding ?
Thanks in advance,

Zlatko

"Rick Brandt" <ri*********@hotmail.com> je napisao u poruci interesnoj
grupi:%T*****************@newssvr17.news.prodigy.c om...
Zlatko Matic wrote:
Hi, Tom!
In fact the only reason why I was looking about late binding is
because I want to distribute .mde to users with different Office
versions. I didn't experience problems with DAO references, but ADO
(msado15.dll), by the way. So, my question could be asked also for
ADO objects (connection object, recordset object, command object...)
as well as for DAO or any other libraries.
I just couldn't find any true example of late binding in Access. Does
anybody use it in real life, after all? Or it is just hipothetical
possibility ?
If it is not common practice, how people solve problems concerning
compatibility on different Office versions ?
It is maybe not a big problem if you distribute .mdb, so every user
can adjust references, but it is not possible in .mde...
How do you solve references problem in .mde ?


I would hazard a guess that for developers that know what there doing that
late binding is overwhelmingly used instead of early binding. I would
NEVER
use early binding except in cases where there is absolute control over the
software that is installed (and isn't installed) on the target PCs. Late
binding is just too darned easy to implement to risk any chance of
versioning problems and broken references that early binding inevitably
produces.

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

Nov 13 '05 #6
"Zlatko Matić" <zl***********@sb.t-com.hr> wrote in
news:de**********@ss405.t-com.hr:
When I execute this function, an error apears: "ActiveX component
can't create an object".
I suppose it is something regarding CurrentDb or DBEngine (0) ?
How to open current database using late binding ?
If you regulary use late binding yould you give me some example of
DAO lata binding ?


Why in the world are you trying to do DAO with late binding? That's
a ridiculously crazy thing to do.

Keep in mind that CurrentDB is both a DAO function and a property of
the Access.Application object. This might give you the ability to do
lots of DAO even without a DAO reference, but I wouldn't know.
Removing the DAO reference seems to me like intentionally cutting
off your legs just before you try to run a marathon.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #7
OK., maybe it is crazy, but still I have my reasons...
Is it possible or not ? If yes, how to achieve late binding of DAO objects ?

"David W. Fenton" <dX********@bway.net.invalid> je napisao u poruci
interesnoj grupi:Xn**********************************@216.196 .97.142...
"Zlatko Matić" <zl***********@sb.t-com.hr> wrote in
news:de**********@ss405.t-com.hr:
When I execute this function, an error apears: "ActiveX component
can't create an object".
I suppose it is something regarding CurrentDb or DBEngine (0) ?
How to open current database using late binding ?
If you regulary use late binding yould you give me some example of
DAO lata binding ?


Why in the world are you trying to do DAO with late binding? That's
a ridiculously crazy thing to do.

Keep in mind that CurrentDB is both a DAO function and a property of
the Access.Application object. This might give you the ability to do
lots of DAO even without a DAO reference, but I wouldn't know.
Removing the DAO reference seems to me like intentionally cutting
off your legs just before you try to run a marathon.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #8
"Zlatko Matić" <zl***********@sb.t-com.hr> wrote in
news:de**********@ss405.t-com.hr:
OK., maybe it is crazy, but still I have my reasons...
Is it possible or not ? If yes, how to achieve late binding of DAO
objects ?


I don't know, and I really couldn't give a rat's ass if it *is*
possible, because it's just about the stupidist thing I've ever
heard of anyone attempting to do.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #9
Hello.
This weekend I succeded to achieve late binding of both DAO and ADO. After I
moved references away, everything worked just good and couldn't see any
significant performance decrease...
Greetings,

Zlatko

"David W. Fenton" <dX********@bway.net.invalid> je napisao u poruci
interesnoj grupi:Xn**********************************@216.196 .97.142...
"Zlatko Matić" <zl***********@sb.t-com.hr> wrote in
news:de**********@ss405.t-com.hr:
OK., maybe it is crazy, but still I have my reasons...
Is it possible or not ? If yes, how to achieve late binding of DAO
objects ?


I don't know, and I really couldn't give a rat's ass if it *is*
possible, because it's just about the stupidist thing I've ever
heard of anyone attempting to do.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Nov 13 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

21 posts views Thread by Mike MacSween | last post: by
1 post views Thread by JD Kronicz | last post: by
5 posts views Thread by eBob.com | last post: by
30 posts views Thread by lgbjr | last post: by
6 posts views Thread by Tim Roberts | last post: by
14 posts views Thread by Siv | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.