[AccessD] Missing references

JWColby jwcolby at colbyconsulting.com
Wed Feb 21 04:49:08 CST 2007


>My understanding is that when an object is just DIMmed space is set aside
for an expected object.

That is correct. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Wednesday, February 21, 2007 3:00 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Missing references

Just a comment...

My understanding is that when an object is just DIMmed space is set aside
for an expected object. It is not until the SET is run that the object
populated with the appropriate methods, properties, events etc.

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Monday, February 19, 2007 8:51 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Missing references


Jim,

  From what I've been told/read in the past, the set statement merely gives
you a pointer to the object and its address lookup table.   With late
binding, VBA does not know the address of the property/method call before
hand, so it must execute a GetIDsOfNames and Invoke call with each
property/method it encounters at runtime.

  With early binding, it already knows the address, so it just needs the
invoke call.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Monday, February 19, 2007 10:36 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Missing references

Jim,


>  It's worse then that; it's a lookup at every property or method call 
> to
the object.

I don't believe so. The set statement essentially loads all that stuff into
memory and is a one time affair (per execution of the set statement).

I think you are thinking of the syntax 

dim MyObject = NEW XXX

In this case the dim and the set statement have been merged into one line of
code and IIRC with this syntax you are correct.

However if you break it out into a separate dim and set statement:

Dim MyObj as object
	set MyOpject = ...

Then the set statement permanently loads the object information for as long
as the object stays in scope.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Monday, February 19, 2007 10:18 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Missing references

John,

<<Late binding performs the LOOKUP of all the data about the object at RUN
TIME, but more specifically at the instant that the SET statement is
executed. >>

  It's worse then that; it's a lookup at every property or method call to
the object.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Monday, February 19, 2007 10:06 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Missing references

As I attempted to explain in my earlier discourse on binding, using an "as
object" syntax is late binding.  The IMPACT of late binding is not as simple
as "the code is loaded" but rather is determined by a myriad of things, but
you can essentially boil it down to "how often is the set statement
encountered".  

Early binding performs the LOOKUP of all the data about the object at
COMPILE TIME. Thus there is NO IMPACT at run time, all the lookup of the
object information has already been done.  

Late binding performs the LOOKUP of all the data about the object at RUN
TIME, but more specifically at the instant that the SET statement is
executed.  Late binding will ALWAYS have some impact (assuming that the set
statement is run) because the lookup must occur.  

I make the disclaimer "assuming the set statement is run" simply because,
for example. I could have an EXCEL class or module in my project.  It
matters not whether it is in the FE or out in a library, what matter is,
whether any code ever tries to ACTUALLY EXECUTE a SET STATEMENT to set a
variable dimensioned as object.  Thus one of my users may use the
application for days and weeks and never experience the impact of late
binding because his job never entails using that EXCEL code.  Another user
may experience the impact of late binding all day every day because his job
requires using the code that executes the set statement, i.e. he uses Excel
and I am late binding excel objects.

NOW... How severe is the impact for that user?  It may be very little or it
may be extreme.  What determines the impact to this user is HOW OFTEN the
set statement is executed, how LONG does it take to perform the binding, and
what % of the total code execution time is taken up by the binding.

Let's take an example.  The code does nothing more than load excel and open
a worksheet.  That would be at least two objects late bound, the Excel
Application, and the worksheet.  The time to bind the object that holds the
pointer to Excel is completely DWARFED by the time to actually load Excel
off the disk.  We are talking a few milliseconds to do the binding and
probably seconds to load excel.  So the user would never even feel the
difference between early and late binding.  The same goes for loading the
spreadsheet itself.  Again, the binding itself takes a few milliseconds, but
loading the worksheet would take a second or two.  The user would never even
feel the difference.

Take another example however.  This user has to load a spreadsheet, and the
code is going to load and manipulate 10 thousand cells, placing data,
formatting it, setting up formulas etc.  NOW the time to reference each cell
may take a few milliseconds but the time to actually manipulate the cells
might well be sub-millisecond.  So late binding in this case could slow down
the app by orders of magnitude.  It could do the whole thing in a second if
early bound but take 10 seconds, 100 seconds etc if late bound.  

The DIFFERENCE is simply that the time to do the binding is occurring
thousands or tens of thousands of times as the program manipulates the
contents of the spreadsheet.  Suddenly milliseconds start to add up.

As you can see, this is a complex subject and one where the answer "is late
binding costing me much" changes radically depending on what the code is
doing.

And it really has nothing to do with when it is loaded and whether it is
sitting in memory.  It is all about how many times the set statements
execute, and how much of the total time those set statements use. 

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of artful at rogers.com
Sent: Monday, February 19, 2007 9:26 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Missing references

You may be right, but it flies in the face of what little I know about
Access. I was under the impression that code sitting in the MDB would be
loaded on first call and thereafter reside in memory. Is that not true when
you do something like create a Word object?

 
Arthur Fuller
Technical Writer, Data Modeler, SQL Sensei Artful Databases Organization
www.artfulsoftware.com




----- Original Message ----
From: Jim Dettman <jimdettman at verizon.net>
To: Access Developers discussion and problem solving
<accessd at databaseadvisors.com>
Sent: Monday, February 19, 2007 8:41:07 AM
Subject: Re: [AccessD] Missing references


Jim,

<<By checking the local references a program can then adapt to its' current
surroundings; but this requires a late-binding design.>>

  How so?  If your dimming something as an object, you using late binding.
I don't know of anyway of changing from late to early without re-compiling
the program.   And if you use late binding, your carrying the performance
hit all the time.

Jim.
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list