Mit welcher Komponente mit Firebird DB verbinden?

[erich.wanker]

Hallo Leute,

welche Komponente empfehlt ihr für Delphi XE4 Prof. - um sich mit einer Firebird 2.5 Datenbank zu verbinden ? (thread save! für ISAPI DLL Anwendung)



Hintergrund:

Ich verwende momentan die Zeos 7.1.0 beta für Delphi XE4 - bei der 7.1.0 Version musste ich zwar was ändern (siehe unten) um es überhaupt installieren zu können, andere Versionen konnte ich gar nicht installieren - oder wenn´s möglich war, waren im DBGrid keine Datensätze sichtbar ...


meine Software (ISAPI - DLL auf einem Apache Server) hängt,
sobald ich eine Reportbuilder15 / ppDBPipeline mit einer Datasource verbinde..

Zitat:

ppdbpipeline1.DataSource:=D_VERTRAG;

Ich vermute, es liegt an Zeos .. oder hat jemand eine andere Vermutung ?


Vielen Dank für Tipps und Hinweise :-)

Danke
Erich


Änderungen an ZAbstractRODataset.pas:

Zitat:

function TZAbstractRODataset.GetRecord(Buffer: PChar; GetMode: TGetMode;
DoCheck: Boolean): TGetResult;
{$ENDIF}
var
RowNo: Integer;
begin
{$IFNDEF WITH_FUNIDIRECTIONAL}
if IsUniDirectional then
Buffer := Pointer(Buffers[0]);
// original Buffer:=Buffers[0];
{$ENDIF}

[Union]

FireDAC wäre ja mal einen Versuch Wert.

[RWarnecke]

UniDAC & Zeos wären zwei weitere Komponenten.

[erich.wanker]

@Union ...

Danke für die Info .. aber zum testen, ob Zeos wirklich schuld ist sind 600€ nicht wenig ;-) .. und ich hab keine FireDAC-Trials gefunden für XE4 :-(

@RWarnecke:

Zeos 7.1 Beta verwende ich grad .. Frage: Weißt du welche ZEOS Version man ohne Fehlermeldungen und Probleme in Delphi XE4 installieren kann ?

Delphi XE4 Professional deutsch auf einem Win8 Rechner


Danke

[DeddyH]

Ich weiß nicht, ob sie unter Delphi XE 4 installierbar sind, aber einen Versuch wäre es wert: Unified Interbase

[Lemmy]

Hi,

zumidnest letzte Wochen liefen die UIB unter XE4 noch nicht. Und wegen 600€: Die IBDac kosten definitiv keine 600€ und sind zudem als Trial zu haben, d.h. da ist es recht problemlos möglich zu testen.

[Union]

Zitat:

Zitat von Lemmy (Beitrag 1222291)

Und wegen 600€: Die IBDac kosten definitiv keine 600€ und sind zudem als Trial zu haben, d.h. da ist es recht problemlos möglich zu testen.

Er bezog sich wohl auf meine Antwort, FireDAC zu testen. Leider habe ich sa und kenne daher gar nicht die Preisgestaltung der Einzelkomponenten.

[RWarnecke]

Zitat:

Zitat von erich.wanker (Beitrag 1222282)

@RWarnecke:

Zeos 7.1 Beta verwende ich grad .. Frage: Weißt du welche ZEOS Version man ohne Fehlermeldungen und Probleme in Delphi XE4 installieren kann ?

Ich habe die 7.1.0-Beta installiert. Die Komponente läuft ohne Probleme. Nimm am besten die Version von SVN.

[Lemmy]

Zitat:

Zitat von Union (Beitrag 1222292)

Zitat:

Zitat von Lemmy (Beitrag 1222291)

Und wegen 600€: Die IBDac kosten definitiv keine 600€ und sind zudem als Trial zu haben, d.h. da ist es recht problemlos möglich zu testen.

Er bezog sich wohl auf meine Antwort, FireDAC zu testen. Leider habe ich sa und kenne daher gar nicht die Preisgestaltung der Einzelkomponenten.

stimmt.. lesen bildet ;-)

[Perlsau]

Zitat:

Zitat von Lemmy (Beitrag 1222291)

Die IBDac kosten definitiv keine 600€ und sind zudem als Trial zu haben, d.h. da ist es recht problemlos möglich zu testen.

Kann ich nur empfehlen. Ich hab zwar nur die Basisversion für 99 Euro erworben, das heißt, ohne Quellcode und minus ein paar Luxus-Komponenten, die man nicht unbedingbt braucht, bin aber dennoch voll zufrieden. Vor allem der Service gefällt mir: Anfragen bei Problemen (oder wenn etwas unklar ist) werden meist noch am selben Tag beantwortet, und zwar sehr kompetent und hilfreich. Kürzlich vermißte ich z.B. die Methode LocateNext, die bei IbDac als LocateOption in ExLocate zu finden ist. Da hätte ich eine ganze Weile zu suchen gehabt, wenn nicht der freundliche Mitarbeiter von Devart mir die Richtung gezeigt hätte.

[DataCool]

Wurde zwar schon genannt, aber scheinbar überlesen !!!

UniDac , UniDac , UniDac .... kostet zwar ein wenig Geld .... ist es aber auf jeden Fall wert !!

Greetz Data

[Perlsau]

[QUOTE=DataCool;1222307]

Zitat:

Zitat von Union (Beitrag 1222265)

UniDac , UniDac , UniDac .... kostet zwar ein wenig Geld .... ist es aber auf jeden Fall wert !!

Mit der Basis-Version von UniDac ist dir nicht gedient, denn da sind keine Provider dabei. Wenn es nur um Firebird- und Interbase-Verbindungen geht, dann genügt IBDac.

[DataCool]

Natürlich die Professional Version !

http://www.devart.com/unidac/editions.html

249 € und dafür Support für mehrere DBs !! Lohnt sich meiner Meinung nach auf jeden Fall.

Greetz Data

[Perlsau]

Zitat:

Zitat von DataCool (Beitrag 1222310)

Natürlich die Professional Version ! 249 € und dafür Support für mehrere DBs !! Lohnt sich meiner Meinung nach auf jeden Fall.

Das kann man so pauschal nicht behaupten. Für mich mit meinen paar Kunden lohnt sich das definitiv nicht! Ich benötige nur Firebird-Zugang. Warum soll ich da 150 Euro mehr ausgeben als nötig?

[DataCool]

Zitat:

Zitat von Perlsau (Beitrag 1222311)

Zitat:

Zitat von DataCool (Beitrag 1222310)

Natürlich die Professional Version ! 249 € und dafür Support für mehrere DBs !! Lohnt sich meiner Meinung nach auf jeden Fall.

Das kann man so pauschal nicht behaupten. Für mich mit meinen paar Kunden lohnt sich das definitiv nicht! Ich benötige nur Firebird-Zugang. Warum soll ich da 150 Euro mehr ausgeben als nötig?

So wärst Du jederzeit in der Lage das DB-System Deiner Applikationen ohne großen Aufwand zu ändern,
allein das wäre mir die Kohle wert.

Wenn es wirklich absolut sicher für alle Ewigkeit nur Firebird sein soll, würde ich mich näher mit UIB beschäftigen,
ich bin mir zwar gerade nicht sicher ob XE4 schon unterstützt wird, wenn nicht wird es bestimmt zeitnah geschehen.

Greetz Data

[EgonHugeist]

Hallo Erich,

wärest du mal hier http://www.delphipraxis.net/175515-z...ml#post1222309 dran geblieben, hätte dir schon eher geholfen werden können..

Nun bevor man eine Komponente wechselt, sollte man mal prüfen, ob es mit einer Alternative funzt und sich dann Ratschläge einholen.

Also wenn du von Zeos weg gehen willst, würde ich in jedem Fall zu FireDac raten. Ist hoch performant in jedem Benchmark nahezu ungeschlagen. Dann wäre noch das Synopse Project.

[Perlsau]

Zitat:

Zitat von DataCool (Beitrag 1222312)

So wärst Du jederzeit in der Lage das DB-System Deiner Applikationen ohne großen Aufwand zu ändern, allein das wäre mir die Kohle wert. Wenn es wirklich absolut sicher für alle Ewigkeit nur Firebird sein soll, würde ich mich näher mit UIB beschäftigen, ich bin mir zwar gerade nicht sicher ob XE4 schon unterstützt wird, wenn nicht wird es bestimmt zeitnah geschehen.

Aber ja, ich kenne diese Argumente, aber du begreifst es offenbar nicht: mit meinen geringen Gewinnen ist es weder drin, 250 Euro für eine DB-Komponente auszugeben noch XE4 zu erwerben oder gar einen neuen schnelleren PC. Ich arbeite mit RadStudio2009 pro, und für meine Bedürfnisse genügt das vollauf. Es geht nicht um alle Ewigkeit, ich werde 53 und habe schätzungsweise noch eine Lebenserwartung von 10 bis 15 Jahren, meinen Gesundheitszustand einberechnet. Ob ich diese Jahre mit Programmieren verbringen werde/kann, bleibt zweifelhaft. Ich hasse es, mich hier so bloßstellen zu müssen, aber wenn es denn nun mal nicht anders geht, um dir aufzuzeigen, daß man diese Aussagen so pauschal nicht treffen kann, dann kann ich auch nichts daran ändern. Auch wenn man das nicht gerne sieht und hört: Es sind nicht alle Leute jung und aufstrebend! Manche sind eben alt und arm und abgerissen, verdienen sich mit Müh und Not ein paar Groschen und haben auch nicht mehr zu erwarten. Was glaubst du wohl, warum Hartz-4 eingeführt wurde? Genau: um solche Schichten zu erzeugen, weil man die besser ausnehmen kann als Vollbürger mit allen Rechten. Aber das geht jetzt zu weit. Für mich ist dieses Thema beendet.

[IBExpert]

ich würde hier auch für IBDAC mit Firebird plädieren. Ist aus meiner Sicht und in vielen Kundenprojekten die beste Wahl.


noch eine Anmerkung:

Als kleiner Softwareanbieter kannst du dich aufhängen, wenn deine Software auf zig Plattformen läuft, weil du dann wahlweise von allen Plattformen nur das benutzen kannst, was alle können und damit nirgendwo wirklich performant sein wirst oder alternativ für jede Plattform das ganze Datenbankdesign noch mal machen kannst.

Diese Pseudo Multi Database Layer im Client sorgen meistens dafür, das du Probleme lösen musst, von denen man keine Ahnung hat. Indexstrukturen, Datentypen, Funktionen des Optimierers und generelle SQL Kompatibilität solltest du nicht ignorieren. Ob du da die Macken von 10 unterschiedlichen Plattformen kennenlernen willst oder dich auf eine Plattform konzentrierst, bei der du zumindest die wichtigsten Dinge kennst, macht für kleine Softwarehäuser eine riesengroßen Unterschied. Oracle oder MS SQL Spezi wird man nicht durch 2 Minuten im Internet surfen.

Das kann aber noch viel gefährlicher werden ....

Wenn dir dann ein ein Mitarbeiter des Kunden auf dem Oracle Server einen Materialized View mit On Commit erstellt und in der nächsten Nacht bei Datenabgleich deiner Software der komplette Datenbankserver lahm liegt, der Kunde dich panisch morgens um 7 anruft, weil das komplette Unternehmen mit hunderten Mitarbeitern still steht und deine Software eindeutig auf Basis der Logs dafür verantortlich ist, dann würdest du dich freuen, nichts mit derem zentralen Datenbanksystem gemacht zu haben.

Der Kunde selbst schwört Stein und Bein, nichts verändert zu haben und der sogenannte Oracle DB Admin hat leider auch keine Ahnung, was das Problem ist und schon gar nicht, was Materialized Views sind und warum die mit on Commit Probleme machen könnten, weil das bei seinem VHS Kurs leider nicht dran war. Man glaubt gar nicht, was für Flachpfeifen da teilweise sehr verantwortungsvolle Positionen bekleiden, weil ja unter den Blinden der Einäugige König ist.

Wenn der Kunde dir dann auf mehrfache Anforderung das Oracle Fehler Protokoll sendet, weil du an der Software seit Monaten nichts mehr geändert hast, dir also keine schuld bewusst bist, dir dann auf den ersten Blick die Fehlermeldungen zum Materialized View auffallen sollten, dann hast du Glück gehabt, das du den Kunde noch mal auf den Pott setzen kannst und ihm zufällig doch einfällt, das er da was an einem View verändert hat.

Alternativ kannst du auch wegen eventueller Schadensersatzforderungen deine Laden gleich zusperren und Hartz4 beantragen.

Die Story ist nicht ausgedacht, sondern real so passiert bei einem französischen Konzern mit deutschen Filialen, für den wir eine Software erstellt haben. Da tanzten schon der erste Manager mit französischem Akzent in Dreieck und wurde ganz still, als der wirklich schuldige im eigenen Haus saß.

Fazit: Mehrere Plattformen zu unterstützen ist nicht immer nur ein Vorteil, sondern manchmal auch brandgefährlich, wenn nicht wirklich auf jeder Plattform 100% fit ist. Für kleine Softwarehersteller ist es unmöglich, auf jeder Datenbankplattform 100% fit zu ein, daher sollte man immer die angeblichen Vorteile im Marketing (multiplattformfähig ...) gegen die Gefahren abwiegen. Multiplattform ist nicht per se besser als single plattform .....

[Perlsau]

Zitat:

Zitat von IBExpert (Beitrag 1222340)

Fazit: Mehrere Plattformen zu unterstützen ist nicht immer nur ein Vorteil, sondern manchmal auch brandgefährlich, wenn nicht wirklich auf jeder Plattform 100% fit ist. Für kleine Softwarehersteller ist es unmöglich, auf jeder Datenbankplattform 100% fit zu ein, daher sollte man immer die angeblichen Vorteile im Marketing (multiplattformfähig ...) gegen die Gefahren abwiegen. Multiplattform ist nicht per se besser als single plattform .....

Sehe ich auch so: Zwar hab ich auch bereits eine Anwendung mit MSSQL, eine mit MySQL und sogar eine mit PostGre entwickelt, doch richtig "anfreunden" konnte ich mich mit keinem der genannten DMBS. Alle drei genannten DBMS bieten sehr umfangreiche Dokmentationen und ebenso viele Features, die ich bei meinen eher kleinen Projekten eigentlich gar nich benötige. Meine Kunden sind kleine Läden (z.B. ein TShirt-Druck-Laden) und vor allem Kleinunternehmer, die gar nicht in der Lage sind, die Kosten für ein Software-Projekt auf einmal zu begleichen. Da wäre alles andere als eine runde Firebird-Datenbankanwendung überdimensioniert.

[Furtbichler]

Zitat:

Zitat von IBExpert (Beitrag 1222340)

Als kleiner Softwareanbieter kannst du dich aufhängen, wenn deine Software auf zig Plattformen läuft, weil du dann wahlweise von allen Plattformen nur das benutzen kannst, ...
Diese Pseudo Multi Database Layer im Client sorgen meistens dafür, das du Probleme lösen musst, von denen man keine Ahnung hat. ...

Endlich mal: Eine fundamental wichtige Aussage von Jemanden, dem man das auch glaubt. :thumb:

Zitat:

Fazit: Mehrere Plattformen zu unterstützen ist nicht immer nur ein Vorteil, sondern manchmal auch brandgefährlich....

Wenn schon multiplattform, dann richtig, ergo: Nichts selbst frickeln, sondern etwas ausgereiftes kaufen.

Wenn ich eine Anwendung hätte, die auf mehreren Plattformen laufen soll, dann hätte ich auch den Umsatz, um mir eine entsprechende Lösung (RemObjects?) zu kaufen, bzw. würde ich das finanzielle Risiko eingehen, hier zu investieren.

Ich habe mich z.B. auf MSSQL eingeschossen. Firebird wäre auch gegangen, aber es war nun einmal SQL-Server von Microsoft. Ich lerne immer mehr, bin mittlerweile halber Spezialist und programmiere daher hochperformante Anwendungen. Nicht, weil die Komponenten so toll sind (mir reicht ADO dicke), sondern weil ich mich mit dem Server mittlerweile so gut auskenne, das ich für so ziemlich jedes Performanceproblem DB-Seitig eine schnelle Lösung finde.

Also: Datenbank aussuchen, Irgendwelche halbwegs bugfreien Komponenten mit Grundfunktionalität nehmen und Erfahrungen sammeln.

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1222356)

Also: Datenbank aussuchen, Irgendwelche halbwegs bugfreien Komponenten mit Grundfunktionalität nehmen und Erfahrungen sammeln.

In der Tat: ein guter Rat :thumb: Genau so macht man das :!:

[Hansa]

Zitat:

Zitat von IBExpert (Beitrag 1222340)

..Ob du da die Macken von 10 unterschiedlichen Plattformen kennenlernen willst oder dich auf eine Plattform konzentrierst, bei der du zumindest die wichtigsten Dinge kennst.....

Ich frage mich schon seit langem, wo der Unsinn mit "mehrere Datenbanken" herkommt. Jedem normalen Programmierer müsste doch wohl klar sein, dass wie im normalen Leben der kleinste gemeinsame Nenner nie und nimmer ein Optimum darstellen kann. FIBplus wurde noch nicht erwähnt. Gibts auch nur für FB/IB. Zumindest kann man sich da sicher sein, dass die sich nicht verzetteln. 8-) Eine weitere Unsitte ist übrigens auch, dem (meist völlig ahnungslosen) Endanwender eine solch schwierige Entscheidung, wie die Auswahl der Datenbank aufzubürden. Für unsereinen ist es zwar einfach, zu sagen, Firebird und basta. Aber Otto-Normaluser vor solch eine Entscheidung zu stellen, das ist völlig überflüssig. Wenn ich die Leute, die jeden Tag mit meinen Programmen arbeiten mal fragen würde, wie die eingesetzte Datenbank eigentlich heisst, dann könnte wohl kein einziger das sagen. Und das ist auch gut so.

[EgonHugeist]

\src\Zeos.inc öffnen

alle nicht Interbase defines wie ENABLE_MYSQL kommentieren und tada.. Zeos kann nur noch FireBird handlen..

[DataCool]

Hi,

Ihr habt alle recht, wenn Ihr wie z.B. Hansa sagt "Support für mehrere DBs gleichzeitig, kann nie das Optimum sein"
das unterschreibe ich auch sofort zu 100% .

Genauso habt Ihr Recht das man sich am besten vor Projektstart auf eine DB festlegt
und dann für diese DB direkt entwickelt.
Mache ich bei meinen Projekten eigentlich auch immer so.

Entwickelt man allerdings Standard-Software oder eine Software die irgendwann "Standard-Software" werden soll
sieht das ganze in meinen Augen etwas anders aus.
Bsp.:
Ein früherer Arbeitgeber von mir hat Software-Produkte im Pflegebereich entwickelt,
Zielgruppe ist breit gefächert vom kleinen Pflegedienst bis hin zur großen Uni-Klinik.
Der kleine Pflegedienst war/ist froh mit Firebird keine extra Lizenz Kosten für die Datenbank zu haben.
Bei den Uni-Kliniken hingegen ist zu 95% schon einen "riesen" DB-Server im Haus vorhanden(MsSQL oder Oracle)
und die Kauf-Entscheider fragen gezielt nach ob das schon vorhandene DB-System unterstützt wird.
Keine Unterstützung des vorhandenen DB-Systems = Produkt ist direkt aus dem Rennen.
.....

Wenn ich mir jetzt IBDAC und UniDAC(beide von DevArt) anschaue, Komponenten vergleiche ....
Dann wage ich mal die Vermutung zu äußern das UniDac einfach einen Abstrakten Wrapper auf Ihre einzelnen Produkte(ODAC, SDAC, MyDAC, IBDAC, PgDAC, LiteDAC)
liefert und somit der Zugriff selber wahrscheinlich sogar die selbe Codebasis hat, deshalb sollte es in meinen Augen keinen großen
Geschwindigkeitsunterschied geben und die Verwendung von UniDac nur eine zusätzliche Option bieten die DB zu wechseln,
WENN man es aus irgendwelchen Gründen muss.
Sollte ich bei der Geschwindigkeitsaussage falsch liegen, werde ich mir für mein nächstes Projekt wohl dann noch IBDac kaufen ...,
aber das werde ich bei Gelegenheit mal in Ruhe mit der Trial Version austesten.

Greeetz Data

[IBExpert]

Zitat:

Zitat von DataCool (Beitrag 1222409)

Hi,
Bei den Uni-Kliniken hingegen ist zu 95% schon einen "riesen" DB-Server im Haus vorhanden(MsSQL oder Oracle)
und die Kauf-Entscheider fragen gezielt nach ob das schon vorhandene DB-System unterstützt wird.
Keine Unterstützung des vorhandenen DB-Systems = Produkt ist direkt aus dem Rennen.

Das Problem ist eindeutig nicht von der Hand zu weisen, aber auch dafür gibt es bewährte Tricks.

Der DB Server des Endkunden wird als Mirror für die Daten in Firebird benutzt.
Durch einfache Scripte werden die relevanten Daten des Firebirdservers in das DBSystem des Kunden
übertragen, via Trigger, Eventalerter, ibeblock und ODBC geht das sogar in nahezu Echtzeit.

Der Firebird Server wird in disem Fall als Application Server betrachtet, der zwar ganz nebenbei auch
SQL kann und auch Daten speichern kann, das interessiert den Kaufentscheider aber relativ selten, da
ja sein Non Plus Ultra Datenbanksystem ja von der Software und dessen Appserver als Storage benutzt wird.
Den fertigen Firebirdbasierenden Appserver liefert man als fertige VM und der Kunde nennt euch nur die
Zugangsdaten zu seiner DB und schon ist alles tuffi ....

Das funktioniert so übrigens wirklich, haben mehrere Kunden von uns Ihren Kunden genau mit dieser
Argumentationskette so umgesetzt.

Das der verantwortliche sich in die Hose pinkelt, wenn irgendeine Software mal nicht auf seiner
bevorzugten DB läuft und er deswegen glaubt, das er ständig Datenverluste hätte, kennt man ja.
Es gibt aber auch gute Argumente dafür, alle Daten in dem zentralen Hobel zu haben, wenn auch nur
als Live Kopie, z.B. Datawarehouse und Reporting. Da würde ich auch nicht die Daten aus dutzenden
Quellen zusammensuchen wollen. Das ist aber mit o.a. Lösung argumentierbar.

Bei kleinen Kunden und kleinen Projekten hat man das Projekt sowieso eher selten, aber wenn du deine
Firebird basierende Anwendung, de nur deswegen so schnell ist, weil du auch die Firebird spezifischen
Features nutzt (SP usw.) und diese dann trotzdem dem Kunden gegenüber mit dem Zusatz
"dedizierter Appserver VM wird mitgeliefert, unterstützte DB Plattform MSSQL,ORACLE,DB2, .... "

Das mal hier so als Hinweis unter uns Pastorentöchtern ....

Immer nicht vergessen:
Leg mal mit deiner Software den zentralen DB Cluster der Klinik lahm, das geht schneller als man denkt
Ich würde da doch lieber nur meine eigene VM lahmlegen, da ich die ja auch gut kenne ....
Und auf der Schnittstelle zur KundenDB laufen eh nur Insert/Updates/Deletes in der einfachsten Form

[Perlsau]

Zitat:

Zitat von Smut (Beitrag 1222410)

Ist es eigentlich möglich, neben IBDAC sich auch UNIDAC zu installieren?

Im Grunde schon. Ich hatte vor einiger Zeit aus Versehen die Basis-Version von UniDac erworben. Als ich nach dem Installieren feststellen mußte, daß da keine Provider dabei sind und ich somit absolut nichts mit UniDac anfangen konnte, hat mir DevArt kulanterwwise die Lizenz getauscht, ohne weitere Euronen dafür in Rechnung zu stellen. Beim Installieren von IbDac hatte ich dann völlig vergessen, daß ja noch UniDac installiert war. Oder beser gesagt: Ich hatte UniDac völlig vergessen, da ich darauf brannte, endlich das (für mich) neue IBDac auszuprobieren. Beim nächsten Update von IbDac wurde ich allerdings darauf hingewiesen, daß ich auch UniDac updaten oder zuvor installieren müsse, sonst würde das Update beim Installieren verweigert. Ich vermute aber, daß beim Erwerb einer größeren als der Basisversion von UniDac auch immer alle Provider aktualisiert wurden, wenn ein neues Release erscheint.

[Lemmy]

Hi,

Zitat:

Zitat von DataCool (Beitrag 1222409)

Sollte ich bei der Geschwindigkeitsaussage falsch liegen, werde ich mir für mein nächstes Projekt wohl dann noch IBDac kaufen ...,
aber das werde ich bei Gelegenheit mal in Ruhe mit der Trial Version austesten.

ich habe hier gerade ein Projekt ADO + ODBC auf MySQL. Unterschied zu MyDac (MySQL direkt) beträgt Faktor 2-2,5. Da lohnt sich der Umbau - wobei der sich zum GLück auf eine einzige Unit beschränkt :-) .
Ich vermute der Unterschied von UniDac zu IBDac dürfte marginal sein. Viel wichtiger ist hier die Unterstützung von DB-spezifischen Features um die DB auszureizen.

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen...."). Funktioniert irgendwie, aber bei keiner DB so richtig.

[Perlsau]

Zitat:

Zitat von Lemmy (Beitrag 1222415)

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen....").

Seh ich ähnlich: man kann entweder viel verschiedenes nur halb oder ein paar wenige Dinge sehr gut. Der Tag hat auch für Multifunktionsthreaduser und eierlegende Wollmilchsäue nur 24 Stunden ... :twisted:

Zitat:

Zitat von Lemmy (Beitrag 1222415)

Funktioniert irgendwie, aber bei keiner DB so richtig.

Ist mir auch schon aufgefallen, deshalb hab ich ja jetzt IbDac ... :thumb:

[Hansa]

Zitat:

Zitat von Lemmy (Beitrag 1222415)

... Viel wichtiger ist hier die Unterstützung von DB-spezifischen Features um die DB auszureizen.

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen...."). Funktioniert irgendwie, aber bei keiner DB so richtig.

Das da widerspricht sich aber doch gewaltig. Ausreizen und kleinster geneinsamer Nenner ? Wie das ? :shock:

[Perlsau]

Zitat:

Zitat von Hansa (Beitrag 1222432)

Zitat:

Zitat von Lemmy (Beitrag 1222415)

... Viel wichtiger ist hier die Unterstützung von DB-spezifischen Features um die DB auszureizen.

Und woher die MultiDB-Unterstützung kommt? Sollte doch klar sein, wenn man eine RAD-IDE hat (Stichwort Klicki-Bunti "... und außerdem können wir mit 15 Datenbanksystemen...."). Funktioniert irgendwie, aber bei keiner DB so richtig.

Das da widerspricht sich aber doch gewaltig. Ausreizen und kleinster geneinsamer Nenner ? Wie das ? :shock:

Verstehe ich nicht: Du selbst hattest doch in Posting Nr. 22 geschrieben: "Jedem normalen Programmierer müsste doch wohl klar sein, dass wie im normalen Leben der kleinste gemeinsame Nenner nie und nimmer ein Optimum darstellen kann."

Was sollte sich da widersprechen? Und auch noch "gewaltig"? Ich jedenfalls kann Lemmy's Ausführungen nicht nur nachvollziehen, sondern ihnen auch zustimmen: Wenn man sich hauptsächlich mit einem DBMS befaßt, lernt man dieses besser kennen als wenn sich man ständig mit verschiedenen DBMS auseinandersetzen muß. Seine Parodie der Reklame für eine bestimmte IDE bringt es auf den Punkt: Was nützt es, wenn mitgelieferte DB-Komponenten zwar irgendwie Kontakt zu zahlreichen DBMS anpreisen, in der Praxis aber unter Fehlern und Performance-Einbrüchen leiden?

[Hansa]

Zitat:

Zitat von Perlsau (Beitrag 1222433)

Seine Parodie der Reklame für eine bestimmte IDE bringt es auf den Punkt: Was nützt es, wenn mitgelieferte DB-Komponenten zwar irgendwie Kontakt zu zahlreichen DBMS anpreisen, in der Praxis aber unter Fehlern und Performance-Einbrüchen leiden?

Aber es stimmt, ich habe Lemmies Ironie unterschätzt. :lol: Unter dem Aspekt gesehen sind wir einer Meinung. 8-)

[mkinzler]

Wobei der Einsatz von Multidatenbank-Komponenten per se nicht unperformant sein muss. UniDAC und FireDAC implementieren auch nicht nur den gemeinsamen Nenner.

[Furtbichler]

Ich glaube, hier werden zwei Use Cases miteinander vermengt:

1. Implementierung einer konkreten Anwendung. Hier ist es für 99% der Anwender sinnvoller, sich auf eine DB einzuschießen. Die individuelle Implementierung irgendwelcher Speziallösungen kann vielleicht für eine bestimmte DB gar nicht oder nur mit Klimmzügen suboptimal möglich sein. Paradebeispiel 'bulk updates' (eigentlich ein ETL-Prozess). Geht mal so, mal so und mal gar nicht (performant). Da kommt man um individuelle Lösungen gar nicht drum herum und muss die unterstützten DB einschränken oder für eine bestimmte DB eine Schrottlösung anbieten.

2. Implementierung eines Dataaccess-Layers. Hier werden 'einfach' die unterschiedlichen DB-Protokolle vereinheitlicht. Eine performante Umsetzung ist hier viel einfacher, denn es müssen nur Basistechnologien (Konnektieren, Befehle abschicken, Daten Empfangen, Fehlerbehandlung) unter einen Hut gebracht werden. bulk updates gehören imho bisher jedenfalls nicht dazu (aus genannten Gründen).