- Local time
- Today, 05:31
- Joined
- Feb 28, 2001
- Messages
- 27,266
I'm going to address another theme: Efficiency.
Access is written in whatever it is written in, probably mostly C++ but heck, that's just a guess. BUT ... it is compiled to machine code level. Very efficient for most things. VERY efficient for any kind of math and for many object property operations because they involve register/indexing off the base of the object's data structure - which hardware supports directly.
If you roll your own equivalent using VB then you can again compile it down to machine code level. Again, register/offset indexing to get properties is a simple thing.
If you use VBA to do everything, remember that VBA is semi-compiled to pseudo-code after which the pseudo-code is interpreted. Right there is a HUGE performance hit. The property pick-up now has to go through all sorts of validation and verification so that you pick up something that is properly defined.
I once wrote an assembler simulator for a different machine's assembler. I got an A+ for the simulator, which had an implementation ratio of between 25 and 50 instructions of my host machine for every simulated instruction. I've seen some fairly fast pseudo-code operations that do a lot of efficient things but that ratio is still up there in the 25+ real instructions to each pseudo-instruction. The overhead to protect the environment is just incredible - and not to be ignored when implementing systems.
So if you wanted to roll your own with VBA, limit that to functions Access does not itself support. OR... if you are good at writing DLL files, you could write your own DLL in VB and then make an external reference to it. With this word of warning - rolling your own DLL works only if you turn down your system security level or if you can digitally sign your DLL file. And even if THAT all works, you have to temper the urge to write in VB because there is overhead in an external call, too.
Generally, when talking efficiency, you just can't beat Access pre-coded queries and other features.
Access is written in whatever it is written in, probably mostly C++ but heck, that's just a guess. BUT ... it is compiled to machine code level. Very efficient for most things. VERY efficient for any kind of math and for many object property operations because they involve register/indexing off the base of the object's data structure - which hardware supports directly.
If you roll your own equivalent using VB then you can again compile it down to machine code level. Again, register/offset indexing to get properties is a simple thing.
If you use VBA to do everything, remember that VBA is semi-compiled to pseudo-code after which the pseudo-code is interpreted. Right there is a HUGE performance hit. The property pick-up now has to go through all sorts of validation and verification so that you pick up something that is properly defined.
I once wrote an assembler simulator for a different machine's assembler. I got an A+ for the simulator, which had an implementation ratio of between 25 and 50 instructions of my host machine for every simulated instruction. I've seen some fairly fast pseudo-code operations that do a lot of efficient things but that ratio is still up there in the 25+ real instructions to each pseudo-instruction. The overhead to protect the environment is just incredible - and not to be ignored when implementing systems.
So if you wanted to roll your own with VBA, limit that to functions Access does not itself support. OR... if you are good at writing DLL files, you could write your own DLL in VB and then make an external reference to it. With this word of warning - rolling your own DLL works only if you turn down your system security level or if you can digitally sign your DLL file. And even if THAT all works, you have to temper the urge to write in VB because there is overhead in an external call, too.
Generally, when talking efficiency, you just can't beat Access pre-coded queries and other features.