4. ODBC ohne BDE?

ODBC ohne BDE?


  • Hallo,

    gibt es eine Möglichkeit, ODBC Datenquellen ohne Installation der BDE nutzen zu können? Im Moment muss auf jedem Rechner, auf dem die Software laufen soll die BDE installiert werden und diese Abhängigkeit würde ich gern irgendwie loswerden.

    0
  • _

    Also für meine MySql Datenbank habe ich den MySql ODBC Connector auf jedem Rechner installiert, und anschließend unter Systemsteuerung->Verwaltung->Datenquellen ODBC die Datenbank angelegt.
    Nun kann das entsprechende Programm die Datenbank verwenden.
    Die Einstellungen sind einmalig, und ich habe mir hierfür ein Batchfile geschrieben, welches ich bei Bedarf bereitstellen kann.
    Ob dies für andere Datenbanksystem genauso funktioniert weiß ich nicht.

    MfG Stephan

    0

  • Das hab´ ich genauso gemacht, auf dem Zielrechner ist der MySQL ODBC Driver 3.51 installiert (der MySQL ODCB Connector 5.17 zickt rum und lässt sich nicht konfigurieren). Auf dem Entwicklungsrechner läuft alles wunderbar, auf dem Zielrechner gibt´s ne Fehlermeldung "Fehler beim Initialisieren der Borland Database Engine $2108" (sinngemäß). Die ist erst verschwunden, nachdem auf dem Zielrechner die BDE 5.1 installiert wurde.
    Und warum zum Geier kann man das nicht statisch linken? Borland punktet wieder mal in der Kategorie "Most complicated procedure" o.O

    0
  • _

    Verwende auch die Version V3.51.25 unter XP.
    Kommt die Fehlermeldung mit der BDE wenn dein Programm zugreifen möchte?
    Hast du mal aus der Verwaltung->ODBC versucht einen Verbindungstest zu machen?

    Verwende das ganze unter BCB V6.0 mit den ADO Komponenten, welche dynamisch erstellt werden.
    Als Datenbank verwende ich MySQL - 5.0.18-nt.

    MfG Stephan

    0

  • Die Fehlermeldung kommt beim ersten Zugriff des Programms auf die DB durch die ODBC Verbindung.
    Das alles läuft unter Windows 7, ODBC Verbindungstest funktioniert einwandfrei.
    Als IDE verwende ich CG2007, das DBMS ist mysql 5.5.6rc und der ODBC Treiber ist MySQL ODBC Driver 3.51.27.00.
    Der Zugriff auf die DB ist trivial, das mache ich mit dynamischen TTable und TQuery Objekten.

    0

  • Du mußt aber schon die ADO Komponenten verwenden (TTable und TQuery verwenden halt die BDE -)

    Edit: die heißen entsprechend TADOTable bzw. TADOQuery...

    0

  • Vielen Dank für die Tipps, ich benutze jetzt die TADOxxxx Klassen, allerdings mit einem merklichen Performanceinbruch. Eine simple Abfrage über 2 Tabellen mit ca. 14.500 Ergebniszeilen braucht ohne Auswertung (alos nur das Durchlaufen der einzelnen Datensätze) knapp 2 Sekunden, da waren die BDE Klassen deutlich schneller.
    Gibt´s da irgendwelche Sachen, die ich noch beachten muss?

    Nachtrag:
    Der MySQL Query Browser führt die gleiche Abfrage in ~0.05 Sekunden aus.

    0
  • ?

    Wie hast Du die CursorLocation eingestellt? Client oder Server? Falls Client (was die Defaulteinstellung ist), stell mal auf Serverseitig um.

    0

  • CursorLocation stand auf clUseClient, hab´s mal mit clUseServer probiert und das brachte etwa 10% mehr Leistung (clUseClient: 1.95 Sekunden, clUseServer: 1.8 Sekunden). Ist immer noch um den Faktor 40 vom MySQL C API entfernt 😕

    0

  • Hallo DocShoe,

    bist du sicher, daß der MySQL Query Browser die kompletten Daten in 0,05sec zieht (oder auch erst beim Scrollen die Daten nachlädt)?

    0

  • Th69 schrieb:

    Hallo DocShoe,

    bist du sicher, daß der MySQL Query Browser die kompletten Daten in 0,05sec zieht (oder auch erst beim Scrollen die Daten nachlädt)?

    Eigentlich schon, bei komplexen Abfragen wird die Anzahl der Treffer in der Statuszeile zyklisch aktualisiert, bis alle Ergebnisse in die Tabelle eingetragen worden sind. Das ist bei meiner Testabfrage nicht so, die Daten stehen quasi ohne Verzögerung zur Verfügung.
    Ich mache morgen mal den direkten Vergleich zwischen ADO und BDE, werde die Ergebnisse dann posten.

    0

  • So, hier die versprochenen Tests, die machen mich wirklich etwas stutzig.
    Testbedingungen, Abfrage über 2 Tabellen

    select * from F, D where F.id=D.file_id

    Tabellendefinitionen:

    Tabelle F mit 502 Einträgen :
   - id int (Primärschlüssel)
   - file_name TEXT
   - start_time DATETIME (indiziert)
   - end_time DATETIME (indiziert)
   - feature1_count
   - feature2_count

Tabelle D mit 27.108 Einträgen
   - id int (Primärschlüssel)
   - file_id (indiziert, FK in Tabelle F)
   - feature1_id (indiziert)
   - feature1_order
   - feature2_id (indiziert)
   - feature2_order
   - count

    Ergebnisse mit MySQL 5.5.6rc, 10 Testläufe

    ADO query returned 27108 records in 6.17003 seconds
ADO query returned 27108 records in 6.37714 seconds
ADO query returned 27108 records in 6.21631 seconds
ADO query returned 27108 records in 6.39774 seconds
ADO query returned 27108 records in 6.31064 seconds
ADO query returned 27108 records in 6.25595 seconds
ADO query returned 27108 records in 6.07631 seconds
ADO query returned 27108 records in 6.25117 seconds
ADO query returned 27108 records in 6.13418 seconds
ADO query returned 27108 records in 6.18922 seconds

BDE query returned 27108 records in 2.84391 seconds
BDE query returned 27108 records in 2.87147 seconds
BDE query returned 27108 records in 2.86973 seconds
BDE query returned 27108 records in 2.90875 seconds
BDE query returned 27108 records in 2.87383 seconds
BDE query returned 27108 records in 2.88704 seconds
BDE query returned 27108 records in 2.89099 seconds
BDE query returned 27108 records in 2.90659 seconds
BDE query returned 27108 records in 2.88467 seconds
BDE query returned 27108 records in 2.89452 seconds

Abfrage über MySQL Query Browser: 0.177 Sekunden

    Ergebnisse mit postgres 9.0

    ADO query returned 27108 records in 20.2785 seconds
ADO query returned 27108 records in 24.2825 seconds
ADO query returned 27108 records in 15.977 seconds
ADO query returned 27108 records in 16.5799 seconds
ADO query returned 27108 records in 10.9756 seconds
ADO query returned 27108 records in 14.6022 seconds
ADO query returned 27108 records in 11.2998 seconds
ADO query returned 27108 records in 22.5153 seconds
ADO query returned 27108 records in 17.9281 seconds
ADO query returned 27108 records in 11.6855 seconds

BDE query returned 27108 records in 18.0997 seconds
BDE query returned 27108 records in 9.90709 seconds
BDE query returned 27108 records in 15.7843 seconds
BDE query returned 27108 records in 18.0613 seconds
BDE query returned 27108 records in 14.9661 seconds
BDE query returned 27108 records in 13.0252 seconds
BDE query returned 27108 records in 16.2438 seconds
BDE query returned 27108 records in 10.8546 seconds
BDE query returned 27108 records in 11.1974 seconds
BDE query returned 27108 records in 8.18426 seconds

Abfrage über pgAdmin III: 2.9 Sekunden

    Alles in allem scheint der Weg über ODBC doch sehr langsam zu sein im Vergleich zur Bneutzung der native API. Ob´s am ODBC Protokoll oder der Borland Implementation liegt kann ich nicht sagen, bin jedoch von der Performance, besonders der von postgres SQL, ziemlich enttäuscht. Da kann man ja fast besser Textdateien nehmen 😮

    0

  • Und jetzt bin ich völlig am Ende...
    Die gleiche Abfrage in C# über ODBC mittels OdbcConnection, OdbcCommand und OdbcDataReader dauert inklusive Auslesen der Ergebniszeilen 0.75 Sekunden!
    Damit dürfte wohl geklärt sein, wo die Performance auf der Strecke bleibt...

    Nachtrag:
    Der obige Testlauf bezieht sich auf MySQL 5.5.6rc, habe gerade den gleichen Test mit C# und postgres 9.0 gemacht und dort braucht C# ziemlich genau 1 Sekunde. Ist zwar immer noch etwas langsamer als MySQL, aber um mindestens den Faktor 15 schneller als der Borland Code.

    0
Anmelden zum Antworten