Bezüglich Datenbank Allgemein:
Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit
Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel
SQL Express, oder Firebird oder
MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?
Doch genau das: Andere Datenbank, anderer Connectionstring und gut ist es.
Es wäre für meine Begriffe recht erbärmlich von Delphi, wenn ich je Datenbank andere Datenbankkomponenten nutzen müsste.
Habe im Laufe meines Lebens so einiges an Software schreiben müssen, bei dem ich zu Beginn der Entwicklung noch nicht wusste, gegen welches
DBMS sie denn letztendlich laufen wird.
Das wäre ja mörderisch, wenn man dann die Software erstmal gegen die zur Entwicklung verfügbare Datenbank mit den passenden Komponenten entwickelt und wenn man dann irgendwann erfährt, dass beim Kunden eine andere Datenbank zum Einsatz kommt, macht man alles, mit anderen Datenbankkomponenten, neu?
Oder die Software kommt bei mehreren Kunden zum Einsatz, aber jeder hat sich für ein anderes
DBMS entschieden? Dann gibt es entsprechend viele Varianten der Software, schön mit jeweils eigenen Komponenten?
Und was ist, wenn aus irgendeinem Grund mal die zuerst gewählte Datenbank wegfällt? Eine Neuentwicklung mit anderen Datenbankkomponenten?
Warum mag man wohl bei den
ADO-Komponenten bei der Erstellung des Connectionstrings eine recht große Auswahl an unterschiedlichen Möglichkeiten zur Erstellung des Connectionstrings und eine (ggfls. systemabhängig) mehr oder weniger große Auswahl an unterschiedlichen
DBMS bekommen? Nur um dann festzustellen, dass es nur gegen
Access funktioniert?
In dem Fall würd' für meine Begriffe die sofortige Deinstallation dieser Komponenten das Einzige sein, was ich mit ihnen mache!
Es gibt diverse Möglichkeiten, um auf Datenbanken zuzugreifen, sei es FireDac, UniDac, dbgo,
ADO, Zeos, (manche kennen noch die
BDE 
) und was weiß der Geier sonst noch.
Sicherlich sollte man am Anfang eine Entscheidung treffen, welche Variante man nutzt.
Aber egal welche man nutzt: Sobald man die Datenbank wechselt, muss man auch die Datenbankkomponeten wechseln?
Das hieße doch letztlich: Für jede Datenbank müsste es eine eigene Palette von entsprechenden Datenbankkomponenten geben. Das wäre ja dann fast schon absurd.
Wo blieben denn da die datenbankunabhängige Entwicklung von Datenbanksoftware?
Brauchen wir dann eventuell für jede Sprache ein eigenes TEdit, ein eigenes TMemo ...
Delphi ist hervorragend dazu geeignet, Datenbanksoftware zu schreiben und ist dabei nicht auf eine bestimmte Datenbank festgelegt. Dies kann nur gelingen, wenn es eben
nicht erforderlich ist, beim Datenbankwechsel die gesamte Datenbankschnittstelle auszutauschen.
Probleme beim Datenbankwechsel kann es geben, wenn sehr datenbankspezifische SQLs genutzt werden. Die eine
DB will halt top 10, die andere first 10, eine andere RowNum < 11, wieder eine andere Limit 10 und das auch noch an unterschiedlichen Stellen des SQLs, nur um an die ersten 10 Zeilen einer Ergebnismenge zu kommen. Das ist aber bei allen Datenbankkomponenten gleich.
Wenn Du mit dem Auto normalerweise über die Autobahn zur Uni/Arbeit/Oma/... fährst und nicht über die Landstraße, wirst Du doch nicht dann, wenn Du ausnahmsweise mal über die Landstraße fährst, vorher einen entsprechenden Motor einbauen? (ja, der Vergleich hinkt.)
Probleme beim Wechsel der Datenbank kann und wird es geben, aber nicht aufgrund der Komponenten, sondern Aufgrund der Unterschiedlichen Syntax im
SQL, sobald man auch nur um Haaresbreite vom (weitgehend einheitlich unterstützten)
SQL-Standard abweicht.
Man muss sich im realen Leben also Gedanken darüber machen, welche Änderungen am
SQL notwendig sind, um mit unterschiedlichen Datenbanken zusammenarbeiten zu können. Und darüber, wie man das im Programm am besten gehändelt bekommt. Hierzu gibt es im Forum schon vielfältige, teils recht kontroverse, Diskussionen. Die solltest Du mal zu Rate ziehen.
ADO ist jetzt vielleicht nicht aus jedermanns Sicht die beste Datenbankschnittstelle, aber welche Datenbank man damit nutzt, sollte egal sein.
Mein konkretes Vorgehen in Deinem Fall wäre:
Connectionstring auf die neue Datenbank ändern, in der neuen Datenbank für das Vorhandensein des benötigten Datenmodells sorgen.
Programm starten und auf Herz und Nieren testen.
Und nur wenn Probleme auftreten nach einer Möglichkeit der Beseitigung suchen und diese (wenn irgend möglich) so wählen, dass das(die) bisher unterstützte(n)
DBMS auch weiterhin genutzt werden kann(können). (Unterschiedliche Lösungsansätze findet man hier im Forum.)