FIBPlus, TbFIBQuery, Close schliesst die

[alex517]

Zitat:

Zitat von hoika

Aber, wenn ich

Delphi-Quellcode:

Query.SQL.Text:= 'Select bla'
Query.ExecQuery;   // = open
Query.Close;

mache, kann ich doch erwarten, dass das Query.Open False ist,
ist es aber nicht ;(

Ich habe es bei mir mit FibQuery probiert,
FibQuery funktioniert genau wie es soll:

Delphi-Quellcode:

qryFzTyp.ExecQuery;
qryFzTyp.Close;
if qryFzTyp.Open then 
  ShowMessage('offen')
else  
  ShowMessage('geschlossen');

Vor qryFzTyp.Close ist qryFzTyp.Open=True,
nach qryFzTyp.Close ist qryFzTyp.Open=False.

Zitat:

Zitat von hoika

Ich habe jetzt das TpFIBDataSet, stelle nun aber leider fest,
dass es langsamer als eine BDE-Query ist.

Keine Ahnung wie du das gemessen hast. Es gibt mit Sicherheit
viele Möglichkeiten die Geschwindigkeit in die eine oder andere
zu beeinflussen. Ich bin mit der Geschwindigkeit von FibPlus
mehr als zufrieden.
Du scheinst die Komponenten aber auch ein wenig "anders" einzusetzten.:gruebel:

alex

[exilant]

Nur mal kurz aus meiner Sicht:

FIBPlus ist nicht BDE kompatibel. Devrace behauptet das auch nicht.

TFibdataset ist nicht langsamer als das TQuery der BDE.

TFibquery ist KEINE "kompatibilitätskomponente" zum "BDE Tquery" sondern es leistet das, was man im allgemeinen von einem Query erwartet. Es kann wirklich alle aktionen auf einer DB ausführen.

Das portieren einer (nichttrivialen) Anwendung von der BDE zu FIBPlus ist ohne
umfangreiche Codeänderungen nicht zu machen. Ich habe eine sehr umfangreiche Anwendung portiert und noch eine weitere vor mir und weiss daher wovon ich rede.

Erwarte nie, dass sich die Komponenten wie die BDE verhalten.

Die Komponenenten sind schnell und robust. Wir arbeiten hier in einer 24/7 Umgebung. Wenn Du einen Fehler findest, gehe davon aus dass entweder in Deinem Code ein Fehler vorliegt oder ein Missverständnis Deinerseits bezüglich der Funktionalität der Komponenten. So war es jedenfalls bei mir immer.

Mache dich vertraut mit den FIBPlus Komponenten und überlege dir dann,
welchen Weg Du bei der Portierung am besten gehst.

Die Portierung lohnt sich.

[alex517]

@exilant: :thumb:
alex

[hoika]

Hallo,

zum Messen der Geschwindigkeit nehme ich meine Unit-Tests (dunit).

einmal mit BDE kompiliert -> 10 Minuten
einmal mit FIBPLUS kompiliert -> 15 Minuten

Vor dem Messen wird FB beendet.

Das ist aber nicht so tragisch,
weil ein normales Programm nie diese Menge SQL-Statements ausführt.


Zur Portierung.
Mein Programm läuft jetzt mit IFDEF BDE als BDE-Programm,
per IFDEF FIBPLUS als FIBPlus-Programm.
Solange nicht die ganzen Anwendungstests (nicht per dunit möglich)
durch sind, läuft es halt noch mit der BDE.

Dazu musste natürlich der komplette Quellcode von TQuery "erlöst" werden.
Es wird jetzt immer TBaseQuery benutzt usw,
d.h. einmal musste ich schon komplett durch.

Delphi-Quellcode:

unit BaseQry0;

interface

uses
  Classes, DB,

 {$IFDEF BDE}
  DBTables,
 {$ENDIF}

 {$IFDEF FIBPLUS}
  pFIBDataSet,
 {$ENDIF}

  jifQry_Types;

{$IFDEF BDE}
type
  TBaseQuery = class(TQuery)
  end;  { TBaseQuery }
{$ENDIF}

{$IFDEF FIBPLUS}
type
  TBaseQuery = class(TpFIBDataSet)
  end;
{$ENDIF}

Noch ein bissel "AutoTransaction" (explizit Transaktionen)
der BDE nachgebaut (wobei das TpFIBDataSet irgendwie schon was drin hat)
Die paar RecordCount-Fehler noch behoben ;)
Aus Params[0] -> Fields[0] usw.

Wird alles von den Unit-Tests gefunden.

Hat übrigens jemand Interesse an einem Tutorial BDE->FIBPlus ?


Heiko

[exilant]

Zitat:

Zitat von hoika

Hallo,

Hat übrigens jemand Interesse an einem Tutorial BDE->FIBPlus ?

Heiko

Klar, immer doch. Ich lerne immer gern von anderen dazu. Das erweitert den Horizont beträchtlich.

Gruß

[hoika]

Hallo,

nun ja, wenn der Code komplett fertsch ist,
werde ich mal was dazu schreiben.


Heiko

[hoika]

Hallo,

kleine Korrektur,

Programm läuft etwa gleich schnell, puh ;)


Heiko

[mkinzler]

Zitat:

Zitat von hoika

Hallo,

kleine Korrektur,

Programm läuft etwa gleich schnell, puh ;)


Heiko

Hätte mich auch sehr gewundert. Wenn du es noch optimierst wird noch einiges möglich sein

[hoika]

Hallo,

hatte das Unidirectional (gibt es in TpFIBQuery, was ich vorher hatte nicht) vergessen ;)
Ausserdem war das FIBPLUS mit MemCheck kompiliert, BDE nicht (unfähr ! ;) ).

Das mit dem Optimieren ist klar,
ich wollte aber erst mal einfach nur die BDE weghaben.

Jetzt müsste ich bei I/U/D nur die TpFIBQuery alleine einsetzn,
dann sollte das wohl etwas schneller gehen.
Nur dummerweise wird bei mir immer pro Tabelle eine DB-Klasse erzeugt,
die eine einzige Query benutzt für alles.
Das jetzt umzustellen ... -> späääääter ;)

Ausserdem benutze ich ja die QSelect-FIBQuery für alle Updates,
das DataSet brauche ich in der Regel auch immer,
und die Zeit für das Create der anderen Queries in der DataSet -> egal.

Jetzt muss ich mir nur noch einen sanfte Umstellung
der Konfiguration überlegen.
Bisher gibt es den BDE-Alias und alternativ (kaum genutzt)
eine Konfigurationsdatei.
Alle Kunden müssten sich jetzt ein Datei "basteln",
dass kann ich aber nith machen.
Also bastel ich mir eine DLL, die, wenn die Konfigurationsdatei fehlt,
per BDE den Alias und damit den Server Name ausliest.

Gibt es eine andere Möglichkeit ?
Wir haben Kunden, da sind stellenweise 50 Rechner mit dem Programm.
Der Admin müsste ja jetzt rumlaufen und überall die Konfigurationsdatei einspielen.


Heiko

[mkinzler]

Vielleicht hilft die Alias-Funktion von FireBird