Memory - Table für IBX

[Dietmar Gellner]

Hallo,
ich arbeite mit D5 und IBX. Gibt es irgendwo ne brauchbare IBX -kompatible MEM - Table - Komponente und wenn ja, wo bekomme ich die her ?

MfG
DieGel

[Torsten Grundke]

Hallo Dietmar,

schau Dir mal die Komponente an http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=15753 .

Ich kenne die Komponente aber nicht. Ich arbeite beeits seit längerer Zeit nicht mehr mit den IBX-Komponenten. Statt dessen verwende ich IB-Objekts für den Zugriff auf Interbase/Firebird.

Tschüß

Torste

[Dietmar Gellner]

Hallo,
IBMemtable 1.1, die dort zu finden ist, kenne und nutze ich bereits.
Ich dachte nur, daß zwischenzeitlich in Anlehnung an D6 auch für
D5 ein TBClientDataset zur Verfügung steht.
Trotzdem vielen Dank !
Viele von meinen Bekannten die mit IB arbeiten schwören auf die IBO. Sind die wirklich erste Wahl oder sollte man nicht (auch wenn es nur aus Gewohnheit geschieht) auch bei den IBX bleiben können ?
Ich hatte mich mal mit 'ner Trust - Version von J.Wharton versucht, bin aber dann, weil eben ein Gewohnheitstier, irgendwo dabei abgestorben. Gibts denn da Speichertabellen - Components ?

MfG
Diege

[Torsten Grundke]

Hallo Dietmar,

Speichertabellen gibt es da nicht. Die Performance der IBO-Komponenten ist im Vergleich zu IBX dramatisch höher. Aktuelle Werte habe ich aber nicht. Zum Umstiegszeitpunkt war das so etwa zwischen Faktor 2 und 10. Die aktuelle Version ist noch schneller. Ich weiß allerdings nicht wie die IBX-Komponenten sich in der Zwischenzeit entwickelt haben.

Für mich ist wichtig, das IBO sehr stabil ist.

Tschüß

Torste

[Andreas Kosch]

Hallo,

>Performance der IBO-Komponenten ist im Vergleich zu IBX dramatisch höher

derartige globale Aussagen sind nicht korrekt. Ich bezweifle sehr stark, dass jemand in einem praktischen Beispiel eine spürbare Performanceverbesserung im Vergleich zu <b>TIBSQL</b> nachweisen kann. Es kommt immer auf die Wahl der "richtigen" Komponenten und den konkreten Einsatzfall (Konfiguration) an. IBO korrigiert im besten Fall Fehlentscheidungen des Entwicklers automatisch, so dass scheinbar eine bessere Performance erzielt wird :-

[Torsten Grundke]

Hallo Andreas,

bei meinen damaligen Versuchen habe ich z.B. ein Select auf eine entsprechend große DB mit der Komponente IBSQL von IBX und IB_Cusor von IBO vorgenommen. Beide Komponenten haben nur einen minimalen Overhead und stellen die jeweils schnellste Zugriffsmöglich auf Interbase dar.

Aber für Dich werde ich noch einmal einen aktuellen Test machen.

Tschüß

Torsten

Ps: den Beitrag zur korrekten Funktion der der IB-Funktion Upper hast Du gesehen

[Andreas Kosch]

Hallo,

&gt;den Beitrag zur korrekten Funktion der der IB-Funktion Upper hast Du gesehen?

ja. Die Prüfung, ob sich der InterBase 6.x an dieser Stelle anders verhält als die 5.x-Versionen, steht auf meiner ToDo-Liste :-

[Bernd Wurm]

Hallo,

ich bin gerade dabei mir die IBO Komponenten genauer anzuschauen, da es ja mit den IBX Komponenten und Firebird 1.5 Probleme geben soll. Ich habe mir ein Objekt geschrieben, mit dem ich wechselseitig mit IBX oder IBO auf IB6.1.6 zugreife. In dem Obejkt werden in abhänigkeit der Verwendeten Komponenten nur die Querykomponenten (TIBQuery oder TIB_Query) gewechselt. Die SQL-Scripts sind die gleichen. Nun habe ich, wie auch hier, gelese das IBO wesentlich schneller sein soll als IBX. Das konnte ich bei mir nicht feststellen. Im Gegenteil IBO ist langsamer. Jetzt kann man aber bei IBO wesentlich mehr in den Eigenschaften einstellen als bei IBX. Wahrscheinlich sind hier meine Einstellungen nicht die Optimalen. Meine Frage: Wie holt man aus IBO die maximale Geschwindigkeit heraus?

Gruß
Bern

[Torsten Grundke]

Hallo Bernd,

In späteren Test's konnte ich die Geschwindigkeitsvorteile für IBO so pauschal nicht mehr reproduzieren. Für eine optimale Performance kommt es bei IBO auf die Wahl der richtig Komponente für den Datenzugriff an.

DDL-Statements sowie SQL-Statement's mit max. einem Ergebnisdatensatz sollten mit IB_DSQL ausgeführt werden. Diese Komponente stellt TIBSQL von IBX weit in den Schatten.

TIB_Cursor ist die ideale Wahl für das sequenzielle Abarbeiten der Ergebnismenge.

Ansonsten verwendet man TIB_Query.

Gruß

Torste

[Bernd Wurm]

Hallo Torsten,

danke für die Antwort. Ich haben bis jetzt nur TIB_Query verwendet. Ich werde die anderen einmal testen.

Ich brauche recht schnelle Komponenten, da ich für ein Filialsystem immer wieder relativ große Datenmengen importieren und exportieren muß. Ich arbeite bei den zu importierenden Datensätzen ausschließlich mit einer ID (Integer) als Hauptschlüssel. Vor den einfügen des Datensatzes überprüfe ich, ob er in der Zieltabelle bereits vorhanden ist. Wenn ja, dann UPDATE sonst INSERT. Ich habe auch schon verschieden DataPump - Module getestet, aber meistens sind die langsamer als die selbstgestrickten.

Vielleicht kennts Du etwas schnelles?

Gruß Bern

[Torsten Grundke]

Hallo Bernd,

in diesem Fall ist beim Export TIB_Cursor das Mittel der Wahl und beim Import TIB_DSQL. Ansonsten ist es sinnvoll für das Insert/Update eine Stored Procedure zu verwenden. Innerhalb der SP prüfst Du ob ein Update oder Insert durchgeführt werden muß und führst es aus. Als Ergebnis bekommst Du eine reduzierte Netzbelastung und eine spürbare Performanceverbesserung.

Unabhängig davon bringt allein der Umstieg von IB 6.0 auf FB 1.5 einen drastischen Performancesprung.

Gruß

Torste