Connection übergeben verschiedene Datenbanken

[matashen]

Hallo zusammen,

nochmal Danke

heut steh ich sowas von aufm Schlauch das ich besser den Rechner runter fahre und erstmal zur Eisdiele gehe.

[himitsu]

@Delphi.Narium

Woher willst du wissen, dass eineVerbindung und myQuery zusammenpassen?
Für den Cast der Query ist somit nur das Zweite richtig, welches die zugehörige Instanz prüft.

Das "MeinZugriff" ist natürlich die zentrale "CreateQuery"-Funktion.
Ob an das nun nochmal trennt oder zusammenwirft, ist jedem selbst überallassen.

Man kann auch mal schauen, denn so manche Connection-Klasse hat auch eine Create/Get-Query-Funktion eingebaut.
z.B. könnte man vom TFDCustomConnection.ExecSQL die Variante mit dem AResultSet benutzen.

Delphi-Quellcode:

function CreateQuery(Connection: TCustomConnection): TDataSet;  // oder ein gemeinsamer TIrgendwasQuery-Vorfahre
begin
  if Connection is TFDCustomConnection then begin
    Result := TFDQuery.Create(nil);
    TFDQuery(Result).Connection := TFDCustomConnection(Connection);
  end else if Connection is TADOConnection then begin
    Result := TADOQuery.Create(nil);
    TADOQuery(Result).Connection := TADOConnection(eineVerbindung);
  end else 
    raise Exception.Create('unbekannte Connection');
end;

Delphi-Quellcode:

function CreateQuery(Connection: TCustomConnection; SQL: string='' {; Params: TParams}): TDataSet;  // oder ein gemeinsamer TIrgendwasQuery-Vorfahre
begin
  Result := nil;
  try
    if Connection is TFDCustomConnection then begin
      Result := TFDQuery.Create(nil);
      TFDQuery(Result).Connection := TFDCustomConnection(Connection);
      if SQL <> '' then begin
        TFDQuery(myQuery).SQL.Text := SQL;
        //TFDQuery(myQuery).Params.Assign(Params);  // oder irgendwie sowas ... z.B. den Params-Parameter als "array of const" oder "array of Variant"
        TFDQuery(myQuery).Open;
      end    
    end else if Connection is TADOConnection then begin
      Result := TADOQuery.Create(nil);
      TADOQuery(Result).Connection := TADOConnection(eineVerbindung);
      if SQL <> '' then begin
        TADOQuery(myQuery).SQL.Text := SQL;
        TADOQuery(myQuery).Open;
      end;
    end else 
      raise Exception.Create('unbekannte Connection');
  except
    Result.Free;  // falls das Open knallte
    raise;
  end;
end;

[Delphi.Narium]

Alles gut und schön.

Die für mich zentrale Frage ist, wieso benötigt man überhaupt unterschiedliche Datenbankkomponenten?

Aus alten Zeiten:

Über die BDE konnte ich damals auf alles zugreifen, was es so an Datenbanken gab.

Später, als die dann obsolet wurde, konnte ich z. B. über ADO auf alles zugreifen, was es dann an Datenbanken gab und heute noch gibt.

Mit Zeos ist es eigentlich ähnlich.

Habe halt kein aktuelles Delphi, aber wenn ich mir mal so die Doku zu TFConnection anschaue, scheint es mir nicht so, als hätte sich diese "altbekannte Flexibilität beim Datenbankzugriff" in heutigen Delphiversionen verschlechtert.

Für mich ist, ehrlich gesagt, die Sinnhaftigkeit des angestrebten Vorgehens nicht erkennbar.

Es wird eine (höchstwahrscheinlich absolut) unnötige, künstliche Komplexität produziert.

Vielleicht sollte man, bevor man hier nach 'ner Lösung für ein Gemisch aus unterschiedlichen Datenbankkomponenten sucht, mal genauer analysieren, was überhaupt gewünscht ist.

Z. B. eine Liste der zu unterstützenden Datenbanken.

Prüfen:

Welche Datenbanken nur über TFDConnection angesprochen werden können, aber nicht über TADOConnection.

Welche Datenbanken nur über TADOConnection angesprochen werden können, aber nicht über TFDConnection.

Sollte es überhaupt Datenbanken geben, die nicht über beide Komponentenarten angesprochen werden können, so wäre hier zuerst mal zu prüfen, in wieweit deren Unterstützung erforderlich ist.

Gibt es derartige Datenbanken nicht, wäre zu prüfen, welche der Komponentenarten am Besten für die gestellte Aufgabe geeignet ist.

Ist tatsächlich eine Mischung beider Komponentenarten erforderlich, so baut man sich dazu z. B. zwei Datenmodule, die jeweils eine Komponentenart unterstützen.

Je nach Datenbank wird dann eines der Datenmodule genutzt.

Aber die Mischung der Zugriffe, über die jeweilige Typabfrage der gerade genutzten Komponenten, dürfte die fehleranfälligste und damit die schlechteste Lösungsmöglichkeit für diese Aufgabenstellung sein.

[MyRealName]

Ich sehe nicht viel Sinn drin, da es ja Sachen wie FireDAC oder UniDAC gibt, aber sei es drum...

Man kann auch für jede Art Verbindung eine Klasse bilden, welche die wichtigen Funktionen, die man so nutzt hinter einem gemeinsamen interface kapselt.

Code:

Type IdbConnection = interface
       procedure Connect(AConnectionStr: String);
       procedure CreateQuery: IdbQuery; // liefert ein interface zu einem query passend zur connection
       // mehr funktionen hier
     end;
     
     TUniDACConnection = class(TInterfaceObject, IdbConnection)
     private
       FDbObject: TUniConnection;  
     public
       procedure Connect(AConnectionStr: String);
       procedure CreateQuery: IdbQuery;
     end;

     TFireDACConnection= class(TInterfaceObject, IdbConnection)
     private
       FDbObject: TUniConnection;  
     public
       procedure Connect(AConnectionStr: String);
       procedure CreateQuery: IdbQuery;
     end;

Muss man natürlich die einzelnen Funktionen, die man so braucht auch extra implementieren, aber naja, so auf die schnelle fällt mir da nichts anderes ein. Damit kannst wohl alles machen, was du brauchst.
Ich würde vielleicht noch eine ConnectionFactory dazubauen, denen gibst Du den Namen des Datenbank-Profils und der baut dir die connection zusammen mit den Parametern des Profils (DBName, Login, zusätzliche Connect-Params...)