TQuery ersetzen

[hoika]

Hallo #,

jaja, die gute alte BDE.
Um mir das ersetzen der BDE zu erleichtern,
habe ich von der normalen TQuery erst mal
eine eigene Klasse (TMyQuery) abgeleitet.

Weiterhin wird jede Query über eine CreateMyQuery erzeugt.

Der nächste Schritt ist jetzt das komplette Ersetzen der
TQuery-Sachen.

Also TBdeQuery von TMyQuery ableiten,
die intern eine normale TQuery (Bde) erzeugt.

Delphi-Quellcode:

type
  TBdeQuery = class(TMyQuery)
    private
      FQuery: TQuery;  // normale Bde-Query
  end;

Weiterhin ne TZeosQuery mit einer TZQuery (?) intern.

Das Open, Execute ist ja noch einfach, aber wie mache ich das mit SQL ?
Wie gesagt, ich will nichts im Programm umschreiben.

ein
Query:= CreateMyQuery mit BDE als "Datenlayer" erzeugt
eine TBdeQuery und gibt die als TMyQuery zurück.

ein Query.SQL.Clear müsste jetzt ja bei der Bde-Query das interne
FQuery.SQL.Clear aufrufen.

Wie könnte man das am einfachsten in der TMyQuery (also virtual) definieren ?

Ich könnte eine Klasse TSQLReplacement erzeugen, die alle SQL-Befehle implementiert,
dann aber eine Methode der TMyQuery aufruft, die wiederum virtual ist,
in den eigentlichen Queries (TBdeQuery, TZeosQuery) überschrieben wird
und dort die internen Queries aufruft.


Danke ich hier zu kompliziert,
geht das auch anders ?

Ist der eigentliche Ansatz zu kompliziert ?

Was ich auch machen möchte, ist mehrere Transaktionen pro Conneciton zu unterstützen,
sofern das der eigentliche Datenlayer unterstützt (also z.B. Zeos),
deshalb der "Umweg" über die eigenen Klassen.


Danke im voraus


Heiko

[Dirk_B]

Zitat von hoika:

Wie gesagt, ich will nichts im Programm umschreiben.

Mit welcher Klasse arbeitet Dein Programm? Wird die Komponente zur Laufzeit
erzeugt oder wurde sie zur Designzeit auf ein Datenmodul gelegt?

Mfg

DB

[hoika]

Hallo Dirk,

teils, teils, dass muss ich auch noch ändern.
Die neuen Sachen werden alle zur Laufzeit erzeugt,
die alten stehen direkt auf den Forms ;(
das wird aber geändert.

Heiko

[Dirk_B]

Also ich würde folgendermaßen vorgehen:

Erzeuge zwei Packages: Beide deklarieren TMyQuery.

Einmal basierend auf der Query von der BDE und einmal auf der
Query von Zeos.

Nun musst Du nur noch dafür sorgen, das beide dieselben Aufrufe verstehen.

Dann installiert Du jeweils das Package, mit dem Du gerade arbeiten willst.

Hinweis: Dieser Ansatz ist sowohl für Designzeit als auch Laufzeit geeignet.
Nicht dagegen verwendbar ist dieser Ansatz für gemischte Projekte.

Allerdings macht das wirklich Sinn? Wenn die Anwendung bereits fertig ist,
kann sie doch so laufen (dann eben mit BDE). Umstellung auf Zeos?
Sicherlich zur Realisierung zwecks Zugriffs auf freien Datenbank-Server?
Warum dann überhaupt noch BDE?

Mfg

DB

[hoika]

Hallo Dirk,

das Programm ist "etwas alt".
In vielen Formularen gibt es noch TTables
(jaja, so hatte das Borland damals wie heute vorgemacht).

Ursprünglich wurde Paradox verwendet.
Ich habe dann in Eigenregie in meiner Freizeit angefangen,
per IFDEF bestimmte Funktionen so ändern,
gerade TTable mit grossen Tabellen sind unter IB ja ein Performance-Graus.

Aus Zeitgründen kann ich aber die Bde nicht so einfach ersetzen,
ausserdem wird weiter dranentwickelt, neue Releases zum Kunden geschickt usw.

Ich stelle mit halt nen sanften Umstieg vor, so wie das damals auch von Pdx->IB gemacht wurde.

Bde ist halt noch drin, weil es zur Zeit nicht anders geht,
aber man muss in die Zukunft schauen.

Mit Vista läuft das Programm noch,
aber ich hatte schon ein paar XP-Probleme,
die ohne Bde nicht geesen wären

(es lag an einer kaputten Windows-Datei,
aber ohne Bde wäre das gar nicht aufgefallen).

Packages wollte ich eigentlich nicht verwenden,
das Teil soll irgendwann auch unter #net laufen,
dort geht das nicht(?).

Mein Ansatz mit der gemeinsamen Basisklase ist wohl schon richtig,
weil Interfaces nicht so unterstützt werden, wie ich das bräuchte.

Die Frage ist nur, wie kann ich z.B. SQL.Add in der Basisklasse definieren ?.


Heiko

[Dirk_B]

Zitat von hoika:

Die Frage ist nur, wie kann ich z.B. SQL.Add in der Basisklasse definieren ?.

Heiko

Du könntest Dein Problem sicherlich mit Interface & Co lösen. Interessannte Materie, wenn man sich die Zeit nimmt.

Die schnelle Variante:

Erzeuge in Deiner Komponente ebenfalls eine Eigenschafft SQL.

Die GetSQL und SetSQL-Routinen könnten jeweils auf BDE.Query.SQL oder ZQuery.SQL zugreifen.

Noch einfacher.

fSQL:=BDE.Query.SQL oder ZQuery.SQL

Musst halt nur nach Erstellung oder Freigabe von BDE.Query oder ZQuery dran denken, fSQL zu aktualisieren.

Mfg

DB

[hoika]

Hallo Dirk,

ja, ist so eine Überlegung von mir.
Aber von welchem Typ wäre SQL denn.

TStrings geht nicht.

SQL.Add muss auch gehen.

Deshalb dachte ich an sowas wie ein Wrapper-Klasse,
die u.a. auch die Methode Add hat.
Die ruft dann eine virtual(abstrakte) Methode
der eigentlichen Query auf, die von den
abgeleiteten Klassen implementiert wird
und dort endlich ( die SQL.Add der richtigen Query aufruft.

Mit Interfaces bin ich übrigens ordentlich auf's M.. gefallen,
so einfach sind die nicht.
Der Weg über die Wrapper-Klasse muss dort aber wohl auch gemacht werden `?

Heiko

[Dirk_B]

Zitat von hoika:

Hallo Dirk,


TStrings geht nicht.

SQL.Add muss auch gehen.

Heiko

Warum geht TStrings nicht? Sieh Dir diesen quick and dirty Code an.

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    ListBox1: TListBox;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

  TBaseClass = class(TObject)
    fSQL : TStrings;
  private
    function GetSQL: TStrings;
    procedure SetSQL(const Value: TStrings);
  public
    { Public declarations }
  property SQL : TStrings read GetSQL write SetSQL;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{ TBaseClass }

function TBaseClass.GetSQL: TStrings;
begin
  Result:=fSQL;
end;

procedure TBaseClass.SetSQL(const Value: TStrings);
begin
  fSQL:=Value;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  with TBaseClass.Create do begin
       SQL:=ListBox1.Items;
       SQL.Add('aa');
  end;
end;

end.

Mfg

DB

[alzaimar]

Also ich habe mal ein ziemlich großes Projekt (ca. 200.000 Codezeilen) in wenigen Stunden komplett von BDE auf ADO umgestellt. Es sind zwar viele Eigenschaften zu ändern (Params/Parameter, die Database in TADOConnection, etc.), aber mit einem automatischen Übersetzer, der die Text-DFM umbastelt, sowie die PAS Dateien zu 95% übersetzt, ging das recht einfach: Schreiben des Übersetzers: ca. 3h, über den Code laufen lassen: 5min, Handarbeit: ca. 5h (Compile, aha, noch ein Bock, zurechtfrickeln, compile ...). Fertig.
Das war nicht schwer, und danach war die alte Tante BDE Historie.

[hoika]

Hallo,

Dirk_B:
naja, mal sehen, ob das mit TQuery auch so geht.

a.. :
naja, ado wolle ich eigentlich nicht mehr nehmen.
Dann wäre der nächste Umstieg ja ado.net.

Vor 5 Jahren hätte ich jetzt nach dem quellcode des Übersetzers gehechelt


Danke

Hieko