LabVIEW
One application, Different ActiveX classes
ADODB is based on Active X too. I'm not very familiar with ADO/DAO as I'm mostly using the standard ODBC API myself, but my guess is that different versions of ADO/DAO implement different amounts of functionality. And the LabVIEW Database Toolkit limits itself to the most common functions of that, both for reasons of support for exotic features that may or may not work with certain database drivers as well as availability only in newer versions of ADO/DAO.
@Dynamik wrote:Hi Folks,I have an app that uses ActiveX to do some simple stuff with MS Access. My (old) 6.1 development station at work has Access 2000 installed. My laptop has Access 97!. When I move the LabVIEW code from work to home, the VI that does the ActiveX stuff complains about a "class not registered".Q. Is it possible (or necessary?) to dynamically examine some list of available classes and make sure the right one is registered, so that the code will survive being moved to different machines? Note: This code needs to be very portable across Windows platforms..Background: It's a database application that talks to MS Access [mostly] via an ADODB Connection. I'd love to do everything through that connection - including execution of Subroutines located inside Modules - but that didn't seem possible, so I've resorted to ActiveX. (If you know how to call Subroutines via the ADODB connection, please reply! )
As such not the use of ActiveX is your problem (ADO/DAO is ActiveX too) but the use of features either ADO/DAO on your older computer does not support or the MS Access 97 database driver does not know about. Your best bet is to make sure that you install the newest ADO/DAO version also on your old computer, although depending on the OS version this may not be supported anymore by that version of ADO/DAO.
Or maybe you are aproaching MS Access directly over its ActiveX Automation interface. Then you will always have troubles. MS Office applications generally add new object classes and properties/methods to their automation interface with each new version and sometimes also change existing classes/properties/methods between versions, making upwards compatibility hard to maintain and downwards compatibility usually impossible.
I think you should be able to call stored procedures (which I assume you mean with subroutines) by building the appropriate SQL statements and send that as a statement to the database but that may be something only real database servers support and may be not available in MS Access.
Rolf Kalbermatter
@rolfk wrote:
Or maybe you are aproaching MS Access directly over its ActiveX Automation interface. Then you will always have troubles. MS Office applications generally add new object classes and properties/methods to their automation interface with each new version and sometimes also change existing classes/properties/methods between versions, making upwards compatibility hard to maintain and downwards compatibility usually impossible.
I think you should be able to call stored procedures (which I assume you mean with subroutines) by building the appropriate SQL statements and send that as a statement to the database but that may be something only real database servers support and may be not available in MS Access.
Rolf Kalbermatter
I must admit that my question was poorly expressed - but then if the concepts were clear to start with, I wouldn't have had any questions! 
I'm mainly using an ADODB connection (which employs ActiveX.) Within MS Access, one can define [VBA] Subroutines within Modules. Maybe it's possible to call subroutines via the ADODB connection, I haven't seen it. Stored Procedures are (I think) a seperate subject, as they are typically written in some flavor of SQL (database-specific). I've read that MS Access is supposed to support Stored Procedures (via ADODB) as early as Access 2000 - but the Procedure can't be developed within the MS Access user-interface! I gave-up trying to get the syntax right through trial-an-error.
So... (having done a bit more research,) I expect to compile/deploy my LabVIEW app with the files (DLLs, OCXs, TLBs) required to support some early version of MS Access application Automation.
Microsoft Windows - the worst OS (except for everything else) 
