Mit
OOP Mitteln ist interessante Frage.
In einem Satz formuliert. Ist dein Problem, dass du in der TCMQueryClass
SQL Statements drinnen hast?
Deine gecashten Objekte schreiben können sich selbst in
DB zurückschreiben, etwas platt formuliert ala object.SetDirty und schon rasseln die
SQL Statements.
Jetzt hast du eine Applikation die auf beide DBs
gleichzeitg zugreift? Soll das so bleiben?
Oder du willst in Zukunft willst du nurmehr auf SQLite gehen oder Wahlweise entweder auf
MySQL XOR MySQLite zugreifen?
Falls nur eine Datenbank in Zukunft gefragt ist migriere den Datenbestand.
---
Dein Problem anders definiert heißt der
SQL String passt nicht zur
DB. In dem Fall bietet sich als billige Variante an die Formatierung des String herauszulösen sofern die Logik für den Zugriff abseits der Basisdatentypen halbwegs indent ist.
Was du brauchst ist eine normiertes
SQL. Am besten ist du machst eine 'globale' Variable in der die ZielDB drinnensteht und eine Funktion FormatSQL('SQLStatement....) : String, welche in Abhängigkeit der Ziel
DB das richtige
SQL zurückgibt.
Die Funktion kann dann die Methode einer Klasse genauso sein und ab dann kannst dahinter rumfuhrwerken wie du willst. Du wirst nicht umhinkommen den Code um zumindest das Klammern der
SQL Statements zu erweitern.
SQL.Format(SELECT_VON_TABELLE);
So etwas in die Richtung oder FormatSQL(SELECT_VON_TABELLE) ist an sich pragmatischer.
Konstanten als 'Symbol' für die
SQL Statements wirst du leider einführen müssen oder du verwendest String Variablen ... In dem Punkt kann man sich schon ausleben. Wesentlich ist die Behandlung der
SQL Statements auf einer 'höheren' Ebene.
Die Prototypen für Formatierung und alles was dazu gehört lagerst du in eine Basisklasse aus. Auf dem Weg geht nicht mehr viel schief. Du kannst die Konstanten in der Klasse definieren usw...
Wenn die Programmlogik sich mit dem Lesen der Blobs massiv ändert müssten wir schauen. Billiger geht es nicht mehr.
Wo du die globale Variable für den Ziel
DB Typ ansiedelst kann ich dir jetzt nicht sagen.