early binding vs late binding
| Author |
Message |
|
boaz
#1 / 10
|
 early binding vs late binding Hi guys, This is my problem. I don't know whether to use early binding or late
binding for the ADODB.
One of my friends told me to use late binding whenever possible.
He said this would solve alot of compatible problems with DLL hell thing.
Originally, I have checked the ADO object library checkbox in the Reference
menu.
I have codes like :
Dim RS as ADODB.Recordset
Set RS = New ADODB.Recordset
My friend told me not to do that.
He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
instead.
Dim RS
Set RS = CreateObect("ADODB.Recordset")
Is it a good thing or bad thing?
--
-
|
| Wed, 22 Oct 2003 07:26:58 GMT |
|
 |
|
Eric
#2 / 10
|
early binding vs late binding Late binding is good because it releases your app from being dedicated to a specifically versioned dll. Early binding is just the opposite. In other words, late binding should prevent you from having to re-compile your app with an UPDATED dll . Early binding means your app maintains a reference to a specific dll. This is the good thing with late binding: you will always maintain a reference to the latest dll regardless of what version it is (as long as naming conventions are the same). DLL HELL becomes an issue when your bound to an older, non backwards compatible library. The worst case scenario with early binding is an app that can break if an updated dll is not backwards compatible. Microsoft, mostly, supports backwards compatibility with their data access technologies (dao, ado,etc.). In your case, it seems to be a nonissue. Use whatever you feel comfortable with but try to realize the reason behind the differences of early and late binding and you'll be fine.
Quote: > Hi guys, > This is my problem. I don't know whether to use early binding or late
> binding for the ADODB.
> One of my friends told me to use late binding whenever possible.
> He said this would solve alot of compatible problems with DLL hell thing.
> Originally, I have checked the ADO object library checkbox in the
Reference
> menu.
> I have codes like :
> Dim RS as ADODB.Recordset
> Set RS = New ADODB.Recordset
> My friend told me not to do that.
> He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
> instead.
> Dim RS
> Set RS = CreateObect("ADODB.Recordset")
> Is it a good thing or bad thing?
> --
> -
|
| Wed, 22 Oct 2003 09:38:45 GMT |
|
|
|
Chris Petche
#3 / 10
|
early binding vs late binding The fact that you have set the reference and are declaring your variables and objects means that you are using Early binding. To use Late binding, you must declare all of your objects as Object or
Variant:
Dim RS as Object
Set RS = CreateObject("ADODB.Recordset")
Yes, it does do away with some of the compatibility issues with component
vesioning known as dll hell, but (a) you will loose the "intellisense" drop
down lists and the compiler syntax checking and (b) if the ADODB.Recordset
object library interface is broken by installing an incompatible version,
then you will still have dll hell because your application wont work
The advantages to early binding are that it is clearer to all programmers
what type of object a variable is, you get the benefit of the intellisense
drop down boxes to get the syntax and spelling of method names correct ( is
it Recordset.GetRow or Recordset.GetRows ?) (Ever spelt Recrdset wrongly?)
Automatic syntax checking.
I guess each to their own.
Quote: > Hi guys, > This is my problem. I don't know whether to use early binding or late
> binding for the ADODB.
> One of my friends told me to use late binding whenever possible.
> He said this would solve alot of compatible problems with DLL hell thing.
> Originally, I have checked the ADO object library checkbox in the
Reference
> menu.
> I have codes like :
> Dim RS as ADODB.Recordset
> Set RS = New ADODB.Recordset
> My friend told me not to do that.
> He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
> instead.
> Dim RS
> Set RS = CreateObect("ADODB.Recordset")
> Is it a good thing or bad thing?
> --
> -
|
| Wed, 22 Oct 2003 23:14:15 GMT |
|
|
|
Neil Woodvin
#4 / 10
|
early binding vs late binding Also worth noting that Late Binding introduces significant performance
degradation as VB must enumerate through the items on the components
interface to find the right item each time a call is made as VB is not aware
of the entry point for each Function call.
I would strongly recommend Early Binding, not only for performance, but as
mentioned by another poster, the in line intellisense and syntax checking is
invaluable.
With a little discipline you should be able to manage compatibility issues
with early binding.
Its a trade off, but I would always go the early binding route.
Cheers,
Neil
Quote: > Hi guys, > This is my problem. I don't know whether to use early binding or late
> binding for the ADODB.
> One of my friends told me to use late binding whenever possible.
> He said this would solve alot of compatible problems with DLL hell thing.
> Originally, I have checked the ADO object library checkbox in the
Reference
> menu.
> I have codes like :
> Dim RS as ADODB.Recordset
> Set RS = New ADODB.Recordset
> My friend told me not to do that.
> He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
> instead.
> Dim RS
> Set RS = CreateObect("ADODB.Recordset")
> Is it a good thing or bad thing?
> --
> -
|
| Thu, 23 Oct 2003 02:04:19 GMT |
|
|
|
boaz
#5 / 10
|
early binding vs late binding Thanks guys! I think I will go change all the CreateObject codes back to New
ADODB.Recordset codes.
This is what I am thinking. Microsoft always make good care of their
products. Any version of ADO
should...(I hope) work across different versions. If not people can just go
install the newest ADO.
The only problem I can see is that if they install the newest ADO, their old
stuffs may not work no more.
Quote: > Hi guys, > This is my problem. I don't know whether to use early binding or late
> binding for the ADODB.
> One of my friends told me to use late binding whenever possible.
> He said this would solve alot of compatible problems with DLL hell thing.
> Originally, I have checked the ADO object library checkbox in the
Reference
> menu.
> I have codes like :
> Dim RS as ADODB.Recordset
> Set RS = New ADODB.Recordset
> My friend told me not to do that.
> He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
> instead.
> Dim RS
> Set RS = CreateObect("ADODB.Recordset")
> Is it a good thing or bad thing?
> --
> -
|
| Fri, 24 Oct 2003 15:21:13 GMT |
|
|
|
Chris Petche
#6 / 10
|
early binding vs late binding The ADODB library is backward compatible ( as should be ALL dlls), so if you install a newer version, the old clients will still work. Obviously if someone has an older version, they need to install the newer version that you wrote your app with, because it may contain functions or classes that dont exist in the older version (For instance the Record object was introduced in ADO 2.5) This is why the microsoft line is that you should always ship ALL components that are used with your app. If the target machine has a newer version than the one you are shipping, the deploment wizard will ignore it, because the newer version will still work. When programmers write classes, we use something called binary compatibility
to make sure that newer versions still work for older clients.
For example: I create an activex dll MyDll which has an object library
MyLib.MyClass
Version 1 has a function TEST, so the client app has some code in it like:
Dim X as MyLib.MyClass
Set X=New MyLib.MyClass
Debug.Print X.Test
Now I make a change to MyClass and add another function "AnotherTest" and a
property "TestResults"
Binary compatibility rules say that the old application will still work
because the original function "TEST" is still there and it hasnt changed.
The original app never used "AnotherTest" or "TestResults" so it doesnt care
whether they are there or not, but version 2 of my app would have some code
to use the new super functions:
Dim X as MyLib.MyClass
Set X=New MyLib.MyClass
Debug.Print X.Test
Debug.Print X.AnotherTest
Debug.Print X.TestResults
Version 3 wont use the Test function at all, but if we take it out (or
change it by adding parameters or anything), the old app wont work any more.
If this is the case we should create a new dll with a new name and a new
library name: MyDLL2 contains MyLib2.MyClass2
Now the old MyDLL is unaffected, and our new app can use the MyLib2.MyClass2
library
Hope this helps
Quote: > Thanks guys! > I think I will go change all the CreateObject codes back to New
> ADODB.Recordset codes.
> This is what I am thinking. Microsoft always make good care of their
> products. Any version of ADO
> should...(I hope) work across different versions. If not people can just
go
> install the newest ADO.
> The only problem I can see is that if they install the newest ADO, their
old
> stuffs may not work no more.
> > Hi guys,
> > This is my problem. I don't know whether to use early binding or late
> > binding for the ADODB.
> > One of my friends told me to use late binding whenever possible.
> > He said this would solve alot of compatible problems with DLL hell
thing.
> > Originally, I have checked the ADO object library checkbox in the
> Reference
> > menu.
> > I have codes like :
> > Dim RS as ADODB.Recordset
> > Set RS = New ADODB.Recordset
> > My friend told me not to do that.
> > He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
> > instead.
> > Dim RS
> > Set RS = CreateObect("ADODB.Recordset")
> > Is it a good thing or bad thing?
> > --
> > -
|
| Fri, 24 Oct 2003 16:45:47 GMT |
|
|
|
Kip Fryma
#7 / 10
|
early binding vs late binding What your saying is true, but then how can you run different versions of the same componant on your PC.. For example I have ADO 2, ADO 2.1, and ADO 2.5 all on my machine and I can pick and choose which one to reference. Does this mean that they do not have the same CLS ID's / GUID's If they were the same then wouldn't they all be under one reference?
Quote: > The ADODB library is backward compatible ( as should be ALL dlls), so if you > install a newer version, the old clients will still work. Obviously if > someone has an older version, they need to install the newer version that > you wrote your app with, because it may contain functions or classes that > dont exist in the older version (For instance the Record object was > introduced in ADO 2.5) > This is why the microsoft line is that you should always ship ALL components > that are used with your app. If the target machine has a newer version than > the one you are shipping, the deploment wizard will ignore it, because the > newer version will still work. > When programmers write classes, we use something called binary
compatibility
> to make sure that newer versions still work for older clients.
> For example: I create an activex dll MyDll which has an object library
> MyLib.MyClass
> Version 1 has a function TEST, so the client app has some code in it like:
> Dim X as MyLib.MyClass
> Set X=New MyLib.MyClass
> Debug.Print X.Test
> Now I make a change to MyClass and add another function "AnotherTest" and
a
> property "TestResults"
> Binary compatibility rules say that the old application will still work
> because the original function "TEST" is still there and it hasnt changed.
> The original app never used "AnotherTest" or "TestResults" so it doesnt
care
> whether they are there or not, but version 2 of my app would have some
code
> to use the new super functions:
> Dim X as MyLib.MyClass
> Set X=New MyLib.MyClass
> Debug.Print X.Test
> Debug.Print X.AnotherTest
> Debug.Print X.TestResults
> Version 3 wont use the Test function at all, but if we take it out (or
> change it by adding parameters or anything), the old app wont work any
more.
> If this is the case we should create a new dll with a new name and a new
> library name: MyDLL2 contains MyLib2.MyClass2
> Now the old MyDLL is unaffected, and our new app can use the
MyLib2.MyClass2
> library
> Hope this helps
> > Thanks guys!
> > I think I will go change all the CreateObject codes back to New
> > ADODB.Recordset codes.
> > This is what I am thinking. Microsoft always make good care of their
> > products. Any version of ADO
> > should...(I hope) work across different versions. If not people can
just
> go
> > install the newest ADO.
> > The only problem I can see is that if they install the newest ADO, their
> old
> > stuffs may not work no more.
> > > Hi guys,
> > > This is my problem. I don't know whether to use early binding or late
> > > binding for the ADODB.
> > > One of my friends told me to use late binding whenever possible.
> > > He said this would solve alot of compatible problems with DLL hell
> thing.
> > > Originally, I have checked the ADO object library checkbox in the
> > Reference
> > > menu.
> > > I have codes like :
> > > Dim RS as ADODB.Recordset
> > > Set RS = New ADODB.Recordset
> > > My friend told me not to do that.
> > > He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
> > > instead.
> > > Dim RS
> > > Set RS = CreateObect("ADODB.Recordset")
> > > Is it a good thing or bad thing?
> > > --
> > > -
|
| Fri, 24 Oct 2003 23:39:40 GMT |
|
|
|
boaz
#8 / 10
|
early binding vs late binding I have noticed that no matter what ADO version I use, VB always points to the file MSADO15.DLL. If I have ADO 2.5, then the version in MSADO15.DLL is 2.5.
Quote: > What your saying is true, but then how can you run different versions of the > same componant on your PC.. For example I have ADO 2, ADO 2.1, and ADO 2.5 > all on my machine and I can pick and choose which one to reference. Does > this mean that they do not have the same CLS ID's / GUID's > If they were the same then wouldn't they all be under one reference?
> > The ADODB library is backward compatible ( as should be ALL dlls), so if
> you
> > install a newer version, the old clients will still work. Obviously if
> > someone has an older version, they need to install the newer version
that
> > you wrote your app with, because it may contain functions or classes
that
> > dont exist in the older version (For instance the Record object was
> > introduced in ADO 2.5)
> > This is why the microsoft line is that you should always ship ALL
> components
> > that are used with your app. If the target machine has a newer version
> than
> > the one you are shipping, the deploment wizard will ignore it, because
the
> > newer version will still work.
> > When programmers write classes, we use something called binary
> compatibility
> > to make sure that newer versions still work for older clients.
> > For example: I create an activex dll MyDll which has an object library
> > MyLib.MyClass
> > Version 1 has a function TEST, so the client app has some code in it
like:
> > Dim X as MyLib.MyClass
> > Set X=New MyLib.MyClass
> > Debug.Print X.Test
> > Now I make a change to MyClass and add another function "AnotherTest"
and
> a
> > property "TestResults"
> > Binary compatibility rules say that the old application will still work
> > because the original function "TEST" is still there and it hasnt
changed.
> > The original app never used "AnotherTest" or "TestResults" so it doesnt
> care
> > whether they are there or not, but version 2 of my app would have some
> code
> > to use the new super functions:
> > Dim X as MyLib.MyClass
> > Set X=New MyLib.MyClass
> > Debug.Print X.Test
> > Debug.Print X.AnotherTest
> > Debug.Print X.TestResults
> > Version 3 wont use the Test function at all, but if we take it out (or
> > change it by adding parameters or anything), the old app wont work any
> more.
> > If this is the case we should create a new dll with a new name and a new
> > library name: MyDLL2 contains MyLib2.MyClass2
> > Now the old MyDLL is unaffected, and our new app can use the
> MyLib2.MyClass2
> > library
> > Hope this helps
> > > Thanks guys!
> > > I think I will go change all the CreateObject codes back to New
> > > ADODB.Recordset codes.
> > > This is what I am thinking. Microsoft always make good care of their
> > > products. Any version of ADO
> > > should...(I hope) work across different versions. If not people can
> just
> > go
> > > install the newest ADO.
> > > The only problem I can see is that if they install the newest ADO,
their
> > old
> > > stuffs may not work no more.
> > > > Hi guys,
> > > > This is my problem. I don't know whether to use early binding or
late
> > > > binding for the ADODB.
> > > > One of my friends told me to use late binding whenever possible.
> > > > He said this would solve alot of compatible problems with DLL hell
> > thing.
> > > > Originally, I have checked the ADO object library checkbox in the
> > > Reference
> > > > menu.
> > > > I have codes like :
> > > > Dim RS as ADODB.Recordset
> > > > Set RS = New ADODB.Recordset
> > > > My friend told me not to do that.
> > > > He said remove the ADODB reference and use
CreateObject("ADODB.xxxx") Quote: > > > > instead. > > > > Dim RS
> > > > Set RS = CreateObect("ADODB.Recordset")
> > > > Is it a good thing or bad thing?
> > > > --
> > > > -
|
| Sat, 25 Oct 2003 00:30:26 GMT |
|
|
|
Kip Fryma
#9 / 10
|
early binding vs late binding ok thats interesting, but why would different entries show up in the references box for each version?
Quote: > I have noticed that no matter what ADO version I use, VB always points to > the file MSADO15.DLL. > If I have ADO 2.5, then the version in MSADO15.DLL is 2.5.
> > What your saying is true, but then how can you run different versions of
> the
> > same componant on your PC.. For example I have ADO 2, ADO 2.1, and ADO
2.5
> > all on my machine and I can pick and choose which one to reference.
Does
> > this mean that they do not have the same CLS ID's / GUID's
> > If they were the same then wouldn't they all be under one reference?
> > > The ADODB library is backward compatible ( as should be ALL dlls), so
if
> > you
> > > install a newer version, the old clients will still work. Obviously if
> > > someone has an older version, they need to install the newer version
> that
> > > you wrote your app with, because it may contain functions or classes
> that
> > > dont exist in the older version (For instance the Record object was
> > > introduced in ADO 2.5)
> > > This is why the microsoft line is that you should always ship ALL
> > components
> > > that are used with your app. If the target machine has a newer version
> > than
> > > the one you are shipping, the deploment wizard will ignore it, because
> the
> > > newer version will still work.
> > > When programmers write classes, we use something called binary
> > compatibility
> > > to make sure that newer versions still work for older clients.
> > > For example: I create an activex dll MyDll which has an object
library
> > > MyLib.MyClass
> > > Version 1 has a function TEST, so the client app has some code in it
> like:
> > > Dim X as MyLib.MyClass
> > > Set X=New MyLib.MyClass
> > > Debug.Print X.Test
> > > Now I make a change to MyClass and add another function "AnotherTest"
> and
> > a
> > > property "TestResults"
> > > Binary compatibility rules say that the old application will still
work
> > > because the original function "TEST" is still there and it hasnt
> changed.
> > > The original app never used "AnotherTest" or "TestResults" so it
doesnt
> > care
> > > whether they are there or not, but version 2 of my app would have some
> > code
> > > to use the new super functions:
> > > Dim X as MyLib.MyClass
> > > Set X=New MyLib.MyClass
> > > Debug.Print X.Test
> > > Debug.Print X.AnotherTest
> > > Debug.Print X.TestResults
> > > Version 3 wont use the Test function at all, but if we take it out (or
> > > change it by adding parameters or anything), the old app wont work any
> > more.
> > > If this is the case we should create a new dll with a new name and a
new
> > > library name: MyDLL2 contains MyLib2.MyClass2
> > > Now the old MyDLL is unaffected, and our new app can use the
> > MyLib2.MyClass2
> > > library
> > > Hope this helps
> > > > Thanks guys!
> > > > I think I will go change all the CreateObject codes back to New
> > > > ADODB.Recordset codes.
> > > > This is what I am thinking. Microsoft always make good care of
their
> > > > products. Any version of ADO
> > > > should...(I hope) work across different versions. If not people can
> > just
> > > go
> > > > install the newest ADO.
> > > > The only problem I can see is that if they install the newest ADO,
> their
> > > old
> > > > stuffs may not work no more.
> > > > > Hi guys,
> > > > > This is my problem. I don't know whether to use early binding or
> late
> > > > > binding for the ADODB.
> > > > > One of my friends told me to use late binding whenever possible.
> > > > > He said this would solve alot of compatible problems with DLL hell
> > > thing.
> > > > > Originally, I have checked the ADO object library checkbox in the
> > > > Reference
> > > > > menu.
> > > > > I have codes like :
> > > > > Dim RS as ADODB.Recordset
> > > > > Set RS = New ADODB.Recordset
> > > > > My friend told me not to do that.
> > > > > He said remove the ADODB reference and use
> CreateObject("ADODB.xxxx")
> > > > > instead.
> > > > > Dim RS
> > > > > Set RS = CreateObect("ADODB.Recordset")
> > > > > Is it a good thing or bad thing?
> > > > > --
> > > > > -
|
| Sat, 25 Oct 2003 01:15:52 GMT |
|
|
|
john
#10 / 10
|
early binding vs late binding backwards compatible? HA!! Microsoft doesnt know what that means. they broke compatibility going from ADO 2.0 to 2.1 and with the Scripting Runtime library (scrrun.dll) when the new version came out for IE 5.0. caused me all sorts of hell. Quote: -----Original Message----- The ADODB library is backward compatible ( as should be ALL dlls), so if you
install a newer version, the old clients will still work. Obviously if
someone has an older version, they need to install the newer version that
you wrote your app with, because it may contain functions or classes that
dont exist in the older version (For instance the Record object was
introduced in ADO 2.5)
This is why the microsoft line is that you should always ship ALL components
that are used with your app. If the target machine has a newer version than
the one you are shipping, the deploment wizard will ignore it, because the
newer version will still work.
When programmers write classes, we use something called binary compatibility
to make sure that newer versions still work for older clients.
For example: I create an activex dll MyDll which has an object library
MyLib.MyClass
Version 1 has a function TEST, so the client app has some code in it like:
Dim X as MyLib.MyClass
Set X=New MyLib.MyClass
Debug.Print X.Test
Now I make a change to MyClass and add another function "AnotherTest" and a
property "TestResults"
Binary compatibility rules say that the old application will still work
because the original function "TEST" is still there and it hasnt changed.
The original app never used "AnotherTest" or "TestResults" so it doesnt care
whether they are there or not, but version 2 of my app would have some code
to use the new super functions:
Dim X as MyLib.MyClass
Set X=New MyLib.MyClass
Debug.Print X.Test
Debug.Print X.AnotherTest
Debug.Print X.TestResults
Version 3 wont use the Test function at all, but if we take it out (or
change it by adding parameters or anything), the old app wont work any more.
If this is the case we should create a new dll with a new name and a new
library name: MyDLL2 contains MyLib2.MyClass2
Now the old MyDLL is unaffected, and our new app can use the MyLib2.MyClass2
library
Hope this helps
> Thanks guys!
> I think I will go change all the CreateObject codes back to New
> ADODB.Recordset codes.
> This is what I am thinking. Microsoft always make good care of their
> products. Any version of ADO
> should...(I hope) work across different versions. If not people can just
go
> install the newest ADO.
> The only problem I can see is that if they install the newest ADO, their
old
> stuffs may not work no more.
> > Hi guys,
> > This is my problem. I don't know whether to use early binding or late
> > binding for the ADODB.
> > One of my friends told me to use late binding whenever possible.
> > He said this would solve alot of compatible problems with DLL hell
thing.
> > Originally, I have checked the ADO object library checkbox in the
> Reference
> > menu.
> > I have codes like :
> > Dim RS as ADODB.Recordset
> > Set RS = New ADODB.Recordset
> > My friend told me not to do that.
> > He said remove the ADODB reference and use CreateObject("ADODB.xxxx")
> > instead.
> > Dim RS
> > Set RS = CreateObect("ADODB.Recordset")
> > Is it a good thing or bad thing?
> > --
> > -
.
|
| Sun, 26 Oct 2003 05:50:12 GMT |
|
| |
|
