[quote=135569:@Kenneth Reed]OK, so I create class named myDatabases or something which contain on ODBC object and a SQLite object.
Not exactly. You create two classes - One that is set up to handle all of the SQLite work that needs to be done and one that handles all the ODBC work that needs to be done. You create a class interface with a set of methods that will basically be your way “in” to those classes from outside. You then add that interface to each class.
Then at startup, the user selects the database he wants to use, which is a switch in the class, like myDatabase.location (local or remote) as string, myDatabase.Query as string, myDatabase.recordset to deliver the results. When i instantiate the object, based on what the user has selected, I open an ODBC object or a SQLite object.
This user sets the database type at startup, the class instantiates the correct database object, and calls the appropriate query. He then returns the record set.
Is this the idea?[/quote]
Again close. The user does select what database type they want to use. Here - let me try to show you with an example…
Here I created two classes - a SQLite Class and an ODBC class. Each contain a respective database object and methods. They are also members of a class interface called DatabaseInterfaceClass. That class has some methods like “Query” assigned to it.
You pick which database you want from the pop-up and then assign the resulting database to the property of the window called DBClass that is of type DatabaseInterfaceClass. You’ll see it all in there. Now when you want to run any of the associated methods, you just call DBClass.Commit or DBClass.Query (actually query is a function that returns a record set). Look at the code in the pushbutton action event.
This example won’t run meaningfully as it’s missing all the database files, etc. but you should be able to see the idea behind the class interface from this. Let me know if you get it.