Set Database Type at Runtime

Can i add a Property of Type Database to a Module and set the Database Type (mySQL, SQlite,…) at Runtime and use it like an “Type of this Database” Property like i would do with a Property i set in the Xojo IDE to Type XYZ?

I once wrote a preferences dialog to select database.
Based on the setting I would initialize the database and return a database object.

If MySQL, it was a MySQLCommunityServer object, but for Postgres as PostgresDatabase object.

In some parts of the app I had to check with isa what object I got exactly.
But no, you can’t change super of a class at runtime.

Thank you @Christian Schmitz
So, i think i will add a dedicated Property for every Database Type i want to support and handle them with IsA.

make a new class “mydatabase”
add a property for each database kind you want to use, there is mainly 2 or 3

or like Christian said, use a database class, and make force use of ISA each time you will use it

in each version, you’re definitely not OOP friendly.

You only need the ISA for database specific things.
All the normal SQL Execute/Select doesn’t need that.

And maybe for a Bind() call.

[quote=354465:@Jean-Yves Pochez]make a new class “mydatabase”
add a property for each database kind you want to use, there is mainly 2 or 3[/quote]

I like the idea and will investigate it. Thank you @Jean-Yves Pochez

Use an interface.

@Oliver Osswald shows one here:

https://forum.xojo.com/43514-multiple-database-options

[quote=354468:@Simon Berridge]Use an interface.

@Oliver Osswald shows one here:

https://forum.xojo.com/43514-multiple-database-options[/quote]

Excellent! Something new to learn. Thank you @Simon Berridge :slight_smile:

[quote=354466:@Christian Schmitz]You only need the ISA for database specific things.
All the normal SQL Execute/Select doesn’t need that.

And maybe for a Bind() call.[/quote]
even a simple sqlquery depends on the database engine.
sqlite is very large with data types, postgres is really not
if you want to get the last inserted row, the syntax is different in each database
for the prepared statements, it’s even worse.
you definitely end with a call different for each dtaabase at the end.

I have taken Oliver’s code and encapsulated it for my use. Pick up a copy here:

dbInterface

Drop the whole folder in your project. The imDB module has a global property db that you use to access your database. This module also has an OpenDatabase method that takes optional parameters for the database type you want to use. In Oliver’s original download there is an MSSQL access module but I don’t use MSSQL so it is not included here.

My changes use SQLite, CubeSQL and PostgreSQL.

Simon.

Done. Thx @Simon Berridge

I will dive into all this at the Weekend. I am sure this will be very helpfull and i will also create my own solution based on Oliver’s and your Code.

Without any exception, i work with Prepared Statements in my planned Project and for this i may have to alter the Code a bit i assume.

BTW: Thank’s go to @Oliver Osswald too :smiley:

This has been the first time that I have worked with an Interface and I am amazed at how great it can be.

I think the answer to your Prepared Statements is to create a new Interface that has the Prepared Statements methods (Bind, BindType, SQLExecute and SQLSelect). Then create a new class for each database and use the specific methods for each. Each class exports a “standard” PreparedStatement.

I’m guessing here but that seems to be the way that Oliver’s code works and I can confirm that it works great for the databases that I use.

Of course you can enchance or rewrite the interface example I have here:
https://forum.xojo.com/43514-multiple-database-options/p1#p353460

In a realworld application my interface contains more signatures (method definitions) than the trimmed example which I used for a presentation at the MBS Xojo conference in Koblenz.

The beauty of it is in writing database specific methods in just one class, which implements the interface. This means, one can quite rapidly support new types of databases, if ever there is such a demand.

And once we understand how interfaces can be useful, we will find many other use-cases and create cleaner code (I wished I knew it right at the beginning …)