FIBPlus, TbFIBQuery, Close schliesst die

[hoika]

Hallo #,

folgender Code checkt, ob bestimmte Felder
in einer Tabelle existieren
(jaja, ich weiss, FIBPlus kann das auch selber, ist eine Portierung)

Delphi-Quellcode:

    
    with Query do
    begin
      SQL.Clear;
      SQL.Add('Select * From Bestellung Where Id=0');   
      Open;                 // hier ist FOpen schon True
      try
        Self.FieldExist.FE_bOrderValue
          := FieldExists(Query, 'OrderValue');
        Self.FieldExist.FE_bAllowDoubleOrderNo
          := FieldExists(Query, 'AllowDoubleOrderNo');
        Self.FieldExist.FE_bUnloadingPlace
          := FieldExists(Query, 'UnloadingPlace') and
             FieldExists(Query, 'UnlPlace_PackSlip');
        Self.FieldExist.FE_bReturnAddress
          := FieldExists(Query, 'ReturnAddress');
      finally
        Close;  // hier bleibt FOpen True
      end;
    end;

Die Query ist eine Ableitung von TpFIBQuery

Delphi-Quellcode:

type
  TBaseQuery = class(TpFIBQuery)
    public
      procedure Close; reintroduce;
  end;

procedure TBaseQuery.Close;
begin
  inherited Close;
 
 // hier ist FOpen False

 // OnClosed event
end;

Das überschriebene Close brauche ich für ein OnClosed event

Das Open ruft direkt ExecQuery auf.


Was mache ich denn falsch.
Der Debugger zeigt mir alles brav an.

*ratlos*


Heiko

[hoika]

Hallo,

kann es am Open liegen.
Das habe ich einfach neu reingepackt,
weil unter der BDE das Open ne Query öffnet.

Wie kann man denn FIBPlus als BDE-Ersatz definieren,
wenn Open eine völlig andere Bedeutung wie in der BDE hat.
Hätte man das nicht IsOpen nennen können ??? *schimpf*

#Update*
OK, im DevGuide steht, man soll TpFIBDataSet nehmen,
aber dann geht die Fummel mit SelectSQL / UpdatedSQL los ;(

Hat hier schon mal jemand in endlicher Zeit eine
BDE-App portiert, ohne ständig im Code rumzufummeln ?.


Heiko

[Artur]

Hallo Hoika,

ja, laut Hilfe Datei ist Open bei FIBplus ein readonly Property, dass die Query activ ist (mit ExecQuery).
Von daher hast Du mit Deinem Vorschlag, dass das eher IsOpen heißen sollte schon recht.
Und noch ein bisschen wilder ist, das es bei den Transactions active und bei der Datenbank connected ist...

BTW: Ich fand beim Umstieg sehr anstregend, dass es keine Table Komponente gibt (dem entspricht ja bei FIBplus das Dataset).
Ansonsten bin ich aber sehr zufrieden damit.

Gruß,

Artur

[hoika]

Hallo,

ich leite jetzt ne eigene Komponente vom TpFIBDataSet ab
und schreibe die fehlenden Sachen dazu.
Wenigstens ist das Open ein richtiges Open ;)
Ist ja vom TDataSet abgeleitet.


Heiko

[mkinzler]

Es ist schon komisch, dass die Komponente TpFIBQuery, welche eigentlich nur aus BDE-Kompatibilitätsgründen vorhanden ist, keine große Kompatibilität zur der aufweist.

[Artur]

Bist Du sicher, das die FIBQuery deshalb drin ist? Ich denke, die ist eher deshalb drin, um nicht alles mit dem "fetten" FIBDataset erledigen zu müssen.

Ciao,

Artur

[mkinzler]

Bei vielen anderen Komponentensammlungen ist das so, könnte aber bei FIBPlus anders sein.

[alex517]

Zitat:

Zitat von mkinzler

Es ist schon komisch, dass die Komponente TpFIBQuery, welche eigentlich nur aus BDE-Kompatibilitätsgründen vorhanden ist, keine große Kompatibilität zur der aufweist.

Die FibQuery hat nichts mit der BDE-Query zu tun und ist schon gar nicht nur Kompatibilitätsgründen vorhanden.

siehe devguide1.pdf

Zitat:

SQL-query execution
An application works with a database by issuing SQL instructions. They are used to get and
modify data\metadata. FIBPlus has a special TpFIBQuery component responsible for SQL
operator execution. This robust, light and powerful component can perform any actions with the
database.
TpFIBQuery is very easy-to-use: just set the TpFIBDatabase component, fill in the SQL
property and call any ExecQuery method (ExecQueryWP, ExecQueryWPS).
NOTE: The tpFIBQuery is not a TDataset descendant, so it does not act in exactly the same
way or exhibit the same methods / properties as you would expect to find in a dataset. For the
TDataset descendant, please refer to the TpFIBDataset.

Ich möchte dir ja nicht zu nahe treten Markus, aber vielleicht
solltes du dich in Bezug auf FibPlus nicht so weit aus dem Fenster lehnen :wink:


alex

[mkinzler]

Hast ja Recht, wenn man keine Ahnung hat, sollte man seine Schnautze halten :oops:

[hoika]

Hallo,

Zitat:

This robust, light and powerful component can perform any actions with the
database.

Ebend nicht, oder anders gesagt, ausser Open.
Das TpFIPQuery ist in der Tat für I/U/D,
sobald ich aber ein Get mache, muss ich manuell an den (BDE)-Code ran.

Ich habe sogar per reintroduce das Open nachbauen wollen,
-> Plautz ;)

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 ;(


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


Heiko

[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

[hoika]

Hallo,

inwiefern ?
Meinst du einen aussagekräftigen DB-Namen per Voreinstellung prüfen ?
Wenn also die Konfigurationsdatei nicht da ist ?

Dann müsste ich aber den Server kennen.


Heiko

[mkinzler]

Ich meinte um den eigentlichen Datenpfad vor dem Client zu verstecken und den Zugriff per Alias zu ermöglichen. Hilft natürlich nichts wenn verschiedene Server verwendet werden.

[hoika]

Hallo,

korrekt.
Aliases benutze ich ja, wenn es geht.

Unter Win98 (jaja, haben manche Kunden noch) gab es aber mal ein Problem,
der Alias-Name konnte nicht aufgelöst werden,
Wurde der normale Pfad angegeben, ging es.


Heiko