Firebird/Interbase OLEDB oder ODBC Treiber gesucht
-
Moin moin!
Wer von euch arbeitet etwas ernsthafter mit Firebird oder Interbase und arbeitet über einen OLEDB Provider oder einen ODBC Treiber? Ich hab stundenlang im Netz gesucht und alle möglichen Freeware Treiber und auch Trial Versionen von kommerziellen ausprobiert aber irgendwie sind die allesamt schrottig. Von schlichtweg nicht unterstützten Features über miese Performance bis hin zu Ausnahmefehlern war alles dabei Das kann doch nicht sein oder?! Zum Testen der Treiber habe ich unterschiedliche Tools (ODBC/ADO Benchmarks, Firebird Tools etc) sowie Firebird 1.5 und 2.0 verwendet und überall kriege ich die selben unbefriedigenden Ergebnisse. Wie machen das die Leute, die professionell mit Firebird/Interbase arbeiten? Programmieren die alle selbst auf dem Native-Interface rum???
Die Datenbank ist ja ne schöne Sache, aber mittlerweile hab ich fast die Nase voll von dem Ding. Hat jemand ne Empfehlung was man am besten verwenden könnte? Darf ruhig Geld kosten.
-
Cpp_Junky schrieb:
Moin moin!
Die Datenbank ist ja ne schöne Sache, aber mittlerweile hab ich fast die Nase voll von dem Ding. Hat jemand ne Empfehlung was man am besten verwenden könnte? Darf ruhig Geld kosten.Im Laufe der Zeit habe ich Erfahrung mit fast allen DBMS gemacht (Exoten ausgenommen). Besonders angetan hatte es mir die SAP-DB. Eingesetzt werden bei uns aber ausnahmslos die Microsoft SQL Server 2005. Die gibt es von kostenlos bis irrsinnig teuer - sauschnell und ultrazuverlässig sind sie aber alle.
SQL Server 2005-Details: http://www.microsoft.com/germany/sql/editionen/default.mspx
Frohes neues Jahr!
-
Naja bei Firebird wollte ich schon bleiben weil ich viel Potential in der Datenbank sehe. Die Frage bezog sich eher auf die Methode der Anbindung: Welcher ODBC Treiber? OLEDB Provider? Oder selbst schreiben übers native API?
-
Also wenn die Basis (ODBC-Treiber) schon mal schlecht ist, dann ist das schlecht. ODBC ist eine nicht unwichtige Schnittstelle, deshalb sollte es einen Wundern, das diese nicht richtig funktioniert. Schon mal bei den Firebird-Leuten nachgefragt?
Für die meisten Anwendungsfälle reicht ja ODBC aus. Ist meine Erfahrung. Aber wenn Firebird und ODBC nicht funktioniert, wirst du die native API nutzen müssen.
Wenn du dein Projekt noch nicht angefangen hast, und du prinzipiell nur ein Interface suchst, dann kannst du evtl. SOCI ausprobieren? Die haben recht viele bekannte native Datenbank-APIs gekapselt. In deinem Fall würdest du SOCI benutzen, und SOCI wiederrum Firebird-API.
Schau mal hier die Features für die Backends:
http://soci.sourceforge.net/doc/backends/index.html
http://soci.sourceforge.net/SOCI ist zwar noch eine junge Library, aber so wie ich es verfolgt habe, ist sie nicht schlecht. Habe sie aber noch nicht getestet. Jedenfalls besser als wenn man direkt die Firebird-API nutzt.
-
Das Problem ist ja nicht, das ODBC generell nicht funktioniert sondern das die Qualität der verfügbaren Treiber so miserabel ist. Das verwundert mich irgendwie. Dieses SOCI werd ich mir mal ansehen, danke.
-
Cpp_Junky schrieb:
Wie machen das die Leute, die [..] mit Firebird/Interbase arbeiten?
Den ADO.NET Provider nehmen
(bzgl "[..]" sage ich nur *röchel* ;D)
-
geeky schrieb:
Den ADO.NET Provider nehmen
Ich hatte den in meinem jugendlichen Leichtsinn echt schon runtergeladen Bin dann aber grad noch zu Bewusstsein gekommen
(bzgl "[..]" sage ich nur *röchel* ;D)
Nana!, Firebird ist IMHO das beste totalkostenlosundmachdamitwasduwillst-Datenbanksystem das es momentan gibt. Leider sind geeignete standardisierte Schnittstellen zu User und Entwickler kaum vorhanden. Naja, ist halt die Kehrseite von Open-Source. Durch den Frickelkram-Dschungel muss man sich erstmal durchschlagen
-
Nichts gegen Firebird (bin eh kein DB-Spezi), aber hast du dir schon mal PostgreSQL angeschaut? Ist eine BSD-lizensierte RDBMS, die auch alle wichtigen Features hat. Wenn du dir deine RDBMS selbst aussuchen kannst (weiß ja nicht welchen Vorgaben du unterliegst) kannst du dir das zumindest anschauen.
Habe mir letztens das Release für Windows installiert und mit dem Admin-Tool gespielt. Funktioniert zumindest auch für einen Nicht-DB-Admin ganz gut.
-
@Cpp_Junky: Ich meinte damit, dass ich Firebird nicht wirklich profesionell nutze
-
Das kann schon sein, dass die Suche unter "Firebird" nicht zum Erfolg führt.
ODBC-Treiber für Interbase oder allgemeine ODBC(-SQL)-Treiber gibt es genug. Die funktionieren auch hervoragend mit Firebird.
-
-
-
hans1 schrieb:
Das sieht interessant aus, danke!
Hans1 schrieb:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_60_odbc
Mit dem hab ich schon jede Menge rumexperimentiert. Nutze den momentan per ADO via ODBC. Der funktioniert noch am besten, hat aber auch so seine Macken - Verursacht z.B. eine Access Violation wenn man bei der Anmeldung falschen User/Passwort übergibt Oder reagiert empfindlich auf berechnete Spalten im Recordset - Die sind zwar problemlos lesbar aber verursachen dabei am laufenden Band Exceptions, was mir irgendwie nicht geheuer ist
-
Dann fang die Exceptions doch ab?
Achja, was sagst du zu SOCI? Doch nicht dein Fall?
-
Artchi schrieb:
Dann fang die Exceptions doch ab?
Ich versuche alle Exceptions abzufangen was normalerweise auch klappt - z.B. bei allen ADO Standardfehlern die so auftreten können, einige kriege ich seltsamerweise aber nicht, wie z.B. das Ding mit den berechneten Spalten. Vielleicht weil sie in der kernel32.dll ausgelöst wird? Der catch-Block greift hier jedenfalls nicht:
Nicht abgefangene Ausnahme in FBTest.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
Achja, was sagst du zu SOCI? Doch nicht dein Fall?
Habs noch nicht live ausprobiert, denk mal ich werd auch erst am Wochenende dazu kommen
-
Die Fehlermeldung kommt mir merkwürdig vor. Bist Du sicher, dass sich im Code oder in der Konfiguration kein Fehler eingeschlichen hat ?
-
Ja, tritt reproduzierbar z.B. beim Selektieren von berechneten Spalten auf. Liegt vermutlich am Spalten-Alias und wie der Treiber damit bei berechneten Feldern umgeht.
Dies bringt den erwähnten Fehler (Ergebnis ist trotzdem lesbar! Der Treiber nennt das Feld dann selbstständig "MENGE" da es keinen Alias gibt) :
select sum(menge) from tabelle
Das selbe Statement mit Alias läuft ohne Exception:
select sum(menge) as gesamt from tabelle
Also denk ich mal es liegt am Treiber. Wieso ich die Exception nicht abgefangen bekomme ist mir allerdings ein Rätsel.
-
"Christoph K. wrote:
Ich habe ein Problem beim Entwickeln unter embedded Visual CE 4.0.
Erhalte beim Ausführen meines Programms ständig Exceptions der Art:First-chance exception in uwpfsdce.exe: 0xE06D7363: Microsoft C++ Exception.
RaiseException: Thread=8f1304a8 Proc=8c09e524 'uwpfsdce.exe'
AKY=00002001 PC=03f9c450 RA=8000eda0 BVA=01a29220 FSR=01a29220Was bedeuten diese Exceptions? Wie kann ich sie vermeiden?
First Chance Exceptions sind kein Problem. Der Debugger teilt dir im wesentlichen nur mit, dass irgendwo gerade eine Exception geworfen wird.
Du erhältst damit die Chance dich zwischen das Werfen der Exception und das Fangen der Exception reinzuhängen wenn du das unbedingt willst.
[Hab ich noch nie gebraucht]Wenn du das nicht willst, wird die Exception normal dem Programm weitergereicht. Wenn du danach nie wieder etwas von ihr hörst, wurde sie gefangen und behandelt.
Solche Exceptions sind auch völlig normal und deuten nicht auf ein Fehlverhalten deines Programmes hin.
mfg
Christoph"
-
Alle ODBC-Treiber, auch für andere Datenbanken, verlangen die Einhaltung spezifischer Konventionen oder die Übergabe entsprechend vereinbarter Strings.
Das ist kein Fehler.