How to refer to objects in referenced db?

[sonic8]

Just a side question... has that ability been present for a long time?

I think, I used this with Access 97 already.
I'm very sure, I used it with Access 2000.
The oldest project in my source code control repository using this approach is from May 2005. (When I started using SCC.)

 

[cheekybuddha]

Can't remeber wherte the code came from but I've used it for years.

See here on UtterAccess

 

[DickyP]

As an aside to the main thread how many others are baffled like me at Microsoft's decision to prevent classes being exposed in referenced access databases?

Seems crass to me, given that most referenced databases usage is for Library databases,

 

[cheekybuddha]

As an aside to the main thread how many others are baffled like me at Microsoft's decision to prevent classes being exposed in referenced access databases?

Seems crass to me, given that most referenced databases usage is for Library databases,

Whilst VBA and VB6 are essentially the same thing, I think MS needed to hobble the VBA environment to prevent you from getting their full premium dev environment for free with your copy of [Office] product.

Annoying? Yes
Understandable? I guess

 

[sonic8]

Whilst VBA and VB6 are essentially the same thing, I think MS needed to hobble the VBA environment to prevent you from getting their full premium dev environment for free with your copy of [Office] product.

They are not the same thing! Particularly not in this context.
An exposed VB6 class is COM compliant.
An exposed VBA class is a bastardized, neutered thing that behaves (with limitations!) like a COM class (rather interface) only within the scope of the distinct VBA project it is loaded into.

I believe the missing Options for the class instancing behavior were omitted deliberately because their effects are not officially documented and came into existence more by chance than by deliberate planning of the responsible dev team.

 

[cheekybuddha]

An exposed VBA class is a bastardized, neutered thing that behaves (with limitations!) like a COM class (rather interface) only within the scope of the distinct VBA project it is loaded into.

Thanks for the correction, Philipp!

 

[The_Doc_Man]

Whilst VBA and VB6 are essentially the same thing, I think MS needed to hobble the VBA environment to prevent you from getting their full premium dev environment for free with your copy of [Office] product.

There is another facet to the difference between VBA and VB6. With VB6 you can create a main program that has a fixed starting point at code you created. For VBA, you cannot do this because the starting point is within whatever is the MAIN program section. The VB6 program can handle all classes of events including direct management of I/O through device-driver calls as well as higher level calls involving "handles". VB6 can (does) create machine-level code but VBA cannot do this. VBA only produces pseudo-code that has to be interpreted because you cannot get Access to DIRECTLY call a VB6 routine. The MSACCESS.EXE code is already compiled and you can't force a direct jump ANYWHERE. You have to use the "hooks" that are event properties in forms and reports. You CAN declare an external entry point (similar to how you call API code) and call some routine from VBA code. But VBA is only useful where the main routine provides "hooks" for callback such as the event routines for forms and reports and the "RunCode" hook for macros.

The main difference between VBA and VB6 is that there is nothing you can do from VBA that will alter a single instruction inside of MSACCESS.EXE, though you can alter some decisions.