Late binding

[Eljefegeneo]

When all the computers at work were upgraded to Windows 10 and Office 365 and I still had my old machine with Office 2010 at home where I do my coding, I had to start using late binding because of some issues with Office 2010 programs; not all of the computers at work were changed over to the new systems at the same time. Now the ones at work have all been converted to either Office 365 or Access 2019 so there no longer exists an issue with having to use late binding. Since I am a programming amateur and often get confused with the nuances of late binding, is it OK to just use early binding with the proper references ticked? I still use Access 2010 at home.

I hope I have explained this clearly. Thanks.

 

[Galaxiom]

You can use the Early Binding references so you get the Intellisense and Late Binding commands to create the objects.

Before you release the database, convert the Early Binding variable declarations to Object.

One way to handle this very sim[ply is with Conditional Compilation. You change one value and the compilation changes throughout.

 

[Eljefegeneo]

Thank you

 

[Pat Hartman]

From a programming perspective, early binding is much more efficient. I always use early binding unless, I have to deal with varying versions as you did.

 

[Eljefegeneo]

Yes, that is why I had to use late binding foe a while. Now testing all the code to make sure all,is ok 2hen I added b@ck the old references.

 

[CJ_London]

@Pat Hartman - I use late binding by default (primarily to avoid support headaches down the line) but have to say, I've never noticed any difference in performance between early and late binding (I develop in early for the intellisense benefits, then convert to late). What sort of efficiency benefits are you referring to or under what circumstances do they become apparent?

Appreciate early binding is a one time load against potential multiple late binding loads, but the time involved is a fraction of a second and can easily be overcome with a single late bind excel/whatever object at program start.

 

[isladogs]

I agree. Generally I develop using early binding for the intellisense, but then change to late binding for deployment.
I see no reason to revert back to early binding even if all workstations are running the same versions of Office.
Even if that's the case now, it won't necessarily be the case at some future time.

If there really is a performance difference between early & late binding, I would expect it to be negligible and not worth worrying about.

 

[Eljefegeneo]

Thank you for all your replies and suggestions. The only reason that I thought about this is that sooner or later I will give up my assistance to the users of the DBs and didn't want to burden them with unnecessary coding. Like me, early binding was easy to figure out. You just added the reference and copies or amended some code or module to suit your purpose. When I had to start using late binding for obvious reasons, I had to learn a new set of rules. Now that the problem of different versions is no longer there, I just thought why not put the references back in and make it a little easier for whomever will be the next coder for all the DBs.

It wasn't a case of speed or any other benefits except making this a little bt easier for my successor whenever that happens.

 

[Isaac]

i would agree try early binding early, late binding later just when deploying.

in vba anyway.

 

[CJ_London]

All I do when converting from early to late is to comment out the early binding code and replace with the late binding - easy enough to convert back if required - just include some instructions as notes to your code