BDE -> FIBPlus

[hoika]

Hallo,

um ein grossen Programm (~600k DB-Code) umzustellen,
bin ich wie folgt vorgegangen.

Ich muss noch dazu sagen, dass das Programm dabei immer noch weiterentwickelt
und ausgeliefert wird.

Noch ein Vorwort.
Da ich mit Interfaces schon mal böse zusammengestossen bin,
verwende ich das Ableiten.

- Definition einer generischen TBaseQuery
alle Methoden/Properties (Open/Close/SQL) sind virtual abstract

- Ableitung einer BDE-Query
es gibt eine interne Query (TQuery)
die abstrakten Methoden werden an diese interne Query einfach weitergeleitet

- Entfernen jeglichen DB-Codes aus den Forms
unit DBTables entfernen, gucken wo es klemmt

- Ersatz aller TTable durch TBaseQuery in den einzelnen
Umschreiben des TTable-Codes auf
-> Heidenarbeit ;(

So !!!!

Das Erzeugen der Queries erfolgt so

Delphi-Quellcode:

function CreateQuery(const theDBEngineType: Integer): TBaseQuery;
begin
  Result:= NIL;

  case theDBEngineType of
    C_EngineType_Bde:
      begin
        Result:= TQuery_Bde.Create(NIL);
      end;
    C_EngineType_FIBPLUS:
      begin
        Result:= TQuery_FIBPlus.Create(NIL);
      end;
  end;
end;  { CreateQuery }

theDBEngineType habe ich erst mal per IFDEF gesetzt


Ich kann jetzt also das Programm als BDE-Version kompilieren,
ohne im Code direkt die BDE zu benutzen.


Jetzt kommt der nächste Schritt .
Transaktionen !!!

Wie das in FIBPlus funktioniert, ist schon klar.

Ich muss aber immer noch den BDE-Code warten,
solange nicht alles funktioniert.

Der Einfachheit halber nehmen wir mal an,
ich brauche erst mal nur ein Transaktion (wie bei der BDE).
Aufrüsten kann man ja immer noch

Jetzt meine Frage.

Ich benutze stellenweise das AutoCommit der BDE,
will auch nicht alle Stellen abändern, um über TDataBase.Cmmit zu arbeiten.

Die TpFIBQuery hat ja auch so ein AutoCommit,
wirkt das genauso ?

Wie bilde ich das sonst am besten nach ?

Also
Query.ExecSQL ohne StartTransaction -> AutoCommit
Query.ExecSQL mit StartTransaction -> kein AutoCommit
(ExecSQL ist ein Bsp, ich weiss es heisst etwas anders)


Ausserdem wird bei der BDE ja per
Query.DataBaseName:= DataBase.DataBaseName das ganze ja per Namen gemacht.

Da ich stellenweise mehrere DB's zur gleichen Zeit abfrage
(verschiedene Queries), müsste ich das ähnlich machen.


Hat jemand eine paar Tips,
wie ich das mit den Transaktionen machen soll ?


Danke


Heiko

[Bernhard Geyer]

Ich würde noch weiter gehen und das Brückenmuster umsetzen. Habens bei unserer App (1,4 Mio. Sourcecodezeilen) auch eingebaut und haben den DBMS-Spezifischen Teil jeweils in 1-2 Units zentriert.

[hoika]

Hallo,

genau das benutze ich doch,
siehe meine CreateQuery-Methode


Heiko

[Bernhard Geyer]

Zitat von hoika:

genau das benutze ich doch,
siehe meine CreateQuery-Methode

Nicht ganz. Dir fehlt noch die Abstraktion-Klasse. Die implementierungs-Klassen werden von dieser Klasse verwendet und werden nicht zum Endkunden gebracht. Deine Implementierung ist eher eine Fabrikmethode

[hoika]

Hallo,

egal, Hauptsache es funktioniert


Heiko

[Bernhard Geyer]

Du könntest aber deine restlichen Sachen wie Transaktion auch in der Abstraktionsschnittstelle verstecken.

[hoika]

Hallo,

ja, das habe ich auch vor !

Das soll ähnlich laufen, wie jetzt bei der BDE.

Der (interne) Code soll sich ja möglichst nicht ändern.

Die Frage ist halt, was mit dem autocommit bei FIBPlus ist.


Heiko

[hoika]

Hallo,

hm,

vielleicht habe ch das mit dem bridge-pattern doch nicht so verstanden.
Jetzt steh ich dumm da ;(

Meine beiden von der abstrakten TBaseQuery abgeleiteten Klassen
brauchen ein FieldByName, umim Code (uiui) z.B. ein FieldByName().AsInteger
zu erlauben.

Jetzt ist die Rückgabe bei TQuery (BDE) aber ein TField
bei TFIBQuery vom Typ TFIBXSQLVAR.

Beide Klassen haben dann aber die entsprechenden AsXXX properties.

Das bringt mir aber nix ;(

Was mache ich denn nu ?
Muss ich etwa einen generische TBaseField-Klasse nehmen,
die erst mal die benötigten AsXXX abstract definiert ?
Das kann doch alles nicht war sein !!!

UIB : gar kein FieldByName
FIBPlus : anderer Typ ;(


*help* ;(


Heiko
PS: Den Link habe ich mir angesehen, Ruby als Quellcode, sind die denn total XXX

[hoika]

Hallo,

erledigt ...
Naja, nicht wirklich ;(

Ich schau mir das jetzt bei tiOPF an.

Wie ich befürchtet habe,
wird dort das ganze TDataSet noch mal nachgebaut.

Vielleicht nehme ich ja das.

Schade um die FIBPlus-Euros.


Heiko