Early & Late Binding

[WayneRyan]

Hey Chris,

Jon is "no longer with us" (Hi Jon!)

I hope that you have a life. Mine got me in trouble last night.

Yes, this has been a good thread. How Access works and how it
thinks is vital.

I haven't followed every second of this, but it's been informative.

Thanks,
Wayne

 

[ChrisO]

No problems here Wayne.

Yes I do have a life, a hobby, a favorite pursuit or pastime.

And that is to try and get people into the habit of questioning things, in this case that which we are “told” about VBA and programming in general.

In the case of timing code, whatever form it takes, it is not only sufficient to find the fastest method but to also try and be realistic about the benefits of doing so.

For example, we run the risk of speed verses readability. If we really want speed then why not use assembly language? Two answers come to mind, one it is too difficult to write and maintain and two it has too high a lead-time to develop anything of substance.

Therefore, if we want speed write in assembler, if we want to get the job done in a reasonble time use something like VBA.

This I’m sure you will see as an exaggeration but the same sort of thing applies within VBA.

Things like the dreaded do lookups are dog slow, but if it is executed once from the click of a button which opens a report…who cares? If the report takes 50 milliseconds longer to open, again…who cares?

And please may I say in passing.

I wasn’t trying to be disparaging towards anyone that took part in the thread. More so to those people that didn’t take part, sit back, and watch the work that goes into it.

BTW, did you come to some understanding of the bound/unbound visible/invisible thing, because that’s where the real delay is hidden?

Regards,
Chris.

 

[WayneRyan]

Chris,

No problems here either.

I appreciate the amount of work that you did on this.

In my Access dealings, I haven't seen any app that based on
a user action (command button, etc.) the wait was INCREDIBLY
slow.

I've seen some non-Access apps (parts break-down) where
when you hit the "go" button it's coffee break time.

Now in SQL Server, when you hit the expand database button
it's gonna be a while. And that's with only like 30 databases
on a "fast" server.

I grew up with assembly language (and even machine code). I
used to be able to read PDP-11 machine code. But they have no
place in today's apps. A 'C' .dll OK.

Most of my apps are financial and/or software problem tracking
and performance is not generally an issue. Even parsed-text
imports from such weird things like Word-Imperfect tables aren't
too bad.

This thread was however a worthwhile endeavor.

Hope to hear from you soon,
Wayne

 

[ChrisO]

Ah the old days.

I got to a point that I could disassemble/understand 6800 Hex at 300 baud, not a thing I would like to go back to.

If you’re into financial stuff, I recently had to write my first aging summary form which was all nicely normalized. Re-calculate everything on the fly.

What a dog to open.

The form was displayed in about 10 seconds, but the grand totals in the form footer took about 70 seconds… after all, the grand total is based on all Customer balances.

Try as I might there seemed no way to overcome the delay.

Answer, when calculating individual invoice item totals in the items table for display purpose only, also save the calculated total back to the invoice table. The aging summary query can then simply sum the invoice totals.

Result, 70 seconds dropped below 1 second. That which was technically correct, but unusable, became technically incorrect but very usable.

Even what we are “told” about normalization needs questioning. It is the overall result that is important, not some theoretical position.

Hope that stirs some people into action.

Regards,
Chris.