|
Datenbank: Firebird • Version: 2.x • Zugriff über: bde
Firebird: Pro und Kontra oder auch Alternativen
Hallo zusammen,
ich habe nun einiges gelesen zu den verschiedenen RDBMS. Ich möchte mich gern für die nächsten Jahre, wenn irgend möglich, auf ein RDBMS festlegen. Allzumal wenn ich mir dazu auch Komponeten kaufen sollte. Allerdings ist mir bei meiner jetzigen Entscheidung für Firebird noch etwas unwohl, weil ich einfach keine Erfahrung habe. Einige Projekte, welche mir im Moment vorschweben, würden Postgre favorisieren (wegen der Volltextsuche). Firebird favorisiert sich aber wegen folgender Merkmale für mich: - kostenlos, auch bei kommerzieller Nutzung - Easy Embedded Installation/Betrieb im Apps-Verzeichnis Meine favorisierten Komponeten für Firebird: - FibPlus - IBExpert Nun meine Fragen an die erfahrenen von Euch: 1.) was spricht evtl. GEGEN Firebird? 2.) gibt es noch ein alternatives RDBMS, welches dann alle Merkmale erfüllt? (kostenlos -auch bei kommerzieller Nutzung-, leichte Embedded Installation/Betrieb, Volltextsuche) 3.) Firebird: was passiert bei einer vorhandenen Server und/oder Client Installation, wenn ich dort mit meiner Embedded Version daher komme? 4.) welche Komponenten oder auch Tools wären "Pflicht" (ich möchte später nicht in Projekten irgend etwas ändern müssen, weil Komponeten ausgetauscht werden müssen) Prinzipiell ist wohl abzusehen, dass für das RDBMS keine "gigantsichen" Datenmengen anfallen werden. Vordergründig werden Suchfunktionen wichtig sein. Danke schon mal vorweg für Eure Hinweise und Ratschläge! |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
-Wenig Sicherheit, bei embedded (jetzige Version) -Trennung Benutzerverwaltung von Datenbank (jetzige Version) Zitat:
Zitat:
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Hast Du schon mal über SQL-Server-Express nachgedacht?
Der ist auch für kommerzielle Anwendungen kostenlos und je nach Anwendungsfall wesentlich schneller als Firebird. mr2 |
Re: Firebird: Pro und Kontra oder auch Alternativen
Ist aber nicht embedded, in der Datenmenge beschränkt.
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Jürgen schreibt doch auch, dass es nicht um enorme Datenmengen gehen wird. Deshalb würde ich auf jedenfall auch mal über die SQL Express Variante nachdenken.
Allerdings ist mir von einer SQL Server Embedded Variante auch nix bekannt. Wenn das eine Forderung an das DB System ist, würde ich auf alle Fälle Firebird ins Visier nehmen. Gibts zwar auch für MySQL, aber ich meine nur für ISAM. Und das hiesse Verzicht auf referenzielle Integrität, also in meinen Augen ein sofortige k.o. Kriterium für eine DB. |
Re: Firebird: Pro und Kontra oder auch Alternativen
Dann möchte ich aber auch einmal Oracle XE zur Diskussion stellen, da sind die Prereqs um einiges moderater als bei SQL Express.
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Alternativen gibt es genug. Allerdings muss man da auch mal eine Kosten/Nutzen-Rechnung aufmachen und abklären, was geht oder was nicht. Ob Oracle, MS-SQL, MySql usw. die sind anfangs kostenlos und irgendwie abgespeckt. Bei FB ist das nicht so. Das wird massiv gesponsort (
 www.sas.com ), sonst würde die Entwicklung auch nicht relativ schnell voran gehen oder es wäre nicht umsonst. Das Stichwort "Volltextsuche" fiel auch noch. Dazu folgendes : IBExpert (die haben nicht nur das Programm "IBExpert" !) hat ein Redaktionssystem für die DPA (aka Deutsche Presseagentur) mit Firebird und FIBPlus realisiert. Kann mir kaum vorstellen, dass da keine guten Suchfunktionen inkl. Volltextsuche drin sind. Nähkästchen : zu ! :mrgreen: |
Re: Firebird: Pro und Kontra oder auch Alternativen
hört ja mit OracleXE und MSSQL Express auf, die Dinger graben sich so tief ins System ein, das ist nicht mehr schön :wall:
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Danke für die Info's! :thumb:
Oracle XE hat mich mit seinen "komischen" Supportbedingungen irgendwie abgeschreckt. Zu MS Express: da habe ich (noch) zu wenig Infos. Bin aber dran. Folgendes möchte ich noch erläutern, weil ich ja nicht genau weiß, ob ich hier überhaupt richtig liege. Warum Embedded? Ich habe einiges dazu gelesen. Die Einschränkungen für Firebird wären für mich hierzu völlig i.O.. Aber es gibt auch Programmierer, welche das komplett ablehnen. Ich möchte die Vorteile und Funktionen eines RDBMS nutzen (hatte vorher erst mit typisierten Dateien geliebäugelt). Allerdings möchte ich mit meiner Entsscheidung für ein DB-System auch unbedingt Inkompatibilitäten mit evtl. schon vorhandenen Versionen, welche auf einigen Rechnern vorhanden sein könnten, aus dem Weg gehen. Wichtig ist auch ein einfaches Setup! Das App-Verzeichnis anlegen, alles reinkopieren -> fertig (da scheint Firebird ja ideal zu sein). Dann soll (zumindest in der Theorie) alles laufen, egal was auf dem Rechner alles so installiert ist. Da wäre halt die Frage, was meine App in Verbindung mit der Embedded-Firebird-Version macht, wenn es auf diesem Rechner schon eine Firebird Server/Client Anwendung gibt? Läuft sowas überhaupt parallel? Oder wenn eine andere Anwendung auch die Embedded Version nutzt... Es ist also das Dillemna: eigene Anwendung mit embedded DB = einfache Integration, keine Systemveränderungen vs. "richtige" Server/Client Installation mit aufwendigem Setup, Integration, Parametrierung, Systemveränderung usw.... Die Kosten/Nutzen- Überlegungen von Hansa spielen natürlich auch eine Rolle, gerade weil es auch verstecket Kosten gibt (bei einigen DB-System zumindest). Bis jetzt scheint Firebird die beste Lösung für mich. Werde mich aber noch weiter informieren. |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Mit folgender Ausnahme : man hält sich an den Microsoft-"Standard". Wenn einer andere Meinung ist, dann ist ausdrücklich erwünscht, eine Antwort zu geben !! Es wird gesagt, dass man sein Programm im User-Verzeichnis speichern soll. Jetzt hat da einer vor 1 Jahr Programm von mir installiert (dürfte noch FB 1.5 gewesen sein). Die GDS32.DLL liegt im User Verzeichnis mitsamt Programm etc. Juergen schickt nächste Woche seins. Auch embedded, aber FB 2.0. Und nu ? :mrgreen: |
Re: Firebird: Pro und Kontra oder auch Alternativen
Guten Morgen!
@Hansa, das hört sich doch richtig gut an! :-D Ich merke es scghon, neuer Thread... FB embedded 1.5er funktioniert dann nicht mit FB 2.x parallel, lässt sich ja nachvollziehen. OK. Wie wirkt sich sowas dann überhaupt aus? Kommen Fehlermeldungen oder bekommt der User gar nichts mit und es könnnte sogar Datenverlust geben (wahrscheinlich ersteres)? Kann man -bevor man das eigene Programm startet- prüfen, ob schon eine andere FB-Instanz läuft? Welchen Prozess (?) müsste ich da suchen (GDS32.DLL)? fröstelnde Grüsse Jürgen [edit=MrSpock]Farbe geändert. Mfg, MrSpock[/edit] |
Re: Firebird: Pro und Kontra oder auch Alternativen
embedded stört sich weder mit anderen embedded-Installationen noch mit Serverinstallationen. Da es sich ja um einen Client handelt, welcher einen Server eingebaut hat. D.h. die Dll öffnet direkt die Datenbankdatei.
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Hast Du als Komponenten für den DB-Zugriff auch die ZEOS in Betracht gezogen?
Die unterstützen Firebird, MySQL, PostgreSQL und noch ein paar weitere Datenbanken. Falls Du dann nicht mehr mit der DB zufrieden bist, kannst Du das in 10 Minuten umbauen. Firebird und PostgreSQL sind beide frei. Von PostgreSQL gibt es allerdings keine Embedded. Ich arbeite jetzt hier seit einem halben jahr mit Firebird 1.5 und er ist mir immernoch nicht richtig sympatisch. In meinen Augen ist das keine "richtige" Datenbank, sondern eine Mischung aus Textfile, Paradox (BDE) und DBMS. Mich stört vor allem, dass die ganze DB in EINEM grossen File verwaltet wird. Obwohl das ja recht praktisch ist, dass man bei der Connection ein anderes File angeben kann und man dann mit einer anderen Datenbank arbeiten kann oder die Datenbank schnell auswechseln kann. |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Zitat:
alex |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Zitat:
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Schaut man sich "richtige" DBMS (z.B. MySQL oder PostgreSQL oder Oracle) an, so haben die für jede Tabelle etliche Files, je eines für die Indexe, Triggers, Struktur, Daten, usw. Somit kann jedes File nicht so riesig werden. Manche DBMS legen sogar eine eigene Partition mit eigenem Filesystem an. |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
zu Paradox? Wo sind Firebird Datenbanken "Textfiles"? Wenn Firebird keine "richtige" Datenbank ist, welche "richtigen" Datenbanken gibt es dann und warum sind sie "richtig" im Vergleich zu Firebird? |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Da gibt es kein grosses File, in dem alles irgendwie drinsteckt. Aber egal. MIR ist Firebird nicht richtig sympatisch und dabei belassen wir es. Bevor ich mir jetzt 1000 Gründe aus den Fingern saugen muss... Und der Vergleich zu Paradox war vielleicht nicht ganz so toll gewählt. |
Re: Firebird: Pro und Kontra oder auch Alternativen
Also bei Oracle, MSSql sind es auch nur einen Datei!
Bei Paradox, Dbase usw waren es auch viele Dateien. Die Anzahl der verwendeten dateien ist bestimmt kein Merkmal eines richtigen DBMS ! |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Wo ist jetzt der entscheidende Beleg dafür, dass Firebird mit einer Datei für die gesamte Datenbank (was so ja auch nicht ganz korrekt ist, man kann das File auch aufteilen) nicht als "richtiges" DBMS gezählt werden kann? Zitat:
alex |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
|
Re: Firebird: Pro und Kontra oder auch Alternativen
@mkinzler:
Also, daß bei Oracle alles in einer Datei ist, wäre mir neu. Ich zumindest lagere jeden Tablespace in eigene Datenfiles aus :-) Grüße, Uli |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Außerdem habe ich die Erfahrung gemacht, daß gerade bei Masseninserts, die für Interbase/Firebird kein Problem darstellen, Oracle mir einen unzureichenden Userspace um die Ohren gehauen hat. Gruß Thomas |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
|
Re: Firebird: Pro und Kontra oder auch Alternativen
@mr2: Gibt es fundierte Erkenntnisse dazu, dass SQL Express unter bestimmten Voraussetzungen schneller als FireBird ist und welche Voraussetzungen wären dies?
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Moin zusammen,
Mit mehreren Embedded-Versionen habe ich auf einem System bisher keine Probleme gehabt. Die fehlende Absicherung ist ein kleines Manko. Dafür spricht aber, dass man einfach "Einkipp und Gut"-Installationen machen kann ohne Registrierung, also kein Systemeingriff. Da Delphi 6 Programme auch unter Wine laufen und Firebird für Linux verfügbar ist, kann man praktisch zwei BS bedienen. Das Einbinden von eigenen UDF´s ist eine Möglichkeit FB auch für Spezialanwendungen mit Delphi zu erweitern. Weiterhin sei ein Hinweis auf Fyracle gegeben, da teilweise gleiche Statements wie in Oracle verwendet werden können, soweit die Aufgaben noch einigermaßen einfach sind. Bei konkurrierenden Schreibzugriffen bietet Oracle mehr Performance. Bei Applikation mit hohem Abfragecharakter ist Firebird eine gute Lösung. Hansa hat oben die Verbindung von SAS und Firebird angesprochen, die funktioniert leider bisher immernoch nur über ODBC. Wenn es mal einen native Driver gibt, dann wird Firebird auch von monetär schwerer gewichteten Projekten verwendet. PostgreSQL ist im Linux-Bereich wahrscheinlich die bessere Alternative, auf Windows Rechner gefällt mir das bisher nicht wirklich, könnte aber noch was werden. PS: Die Zugriffmöglichkeiten sind eingentlich ein eigener Thread: FibPlus und Zeos sind beides schnelle Komponenensammlungen und haben beide ihre Stärken und Schwächen. Das Transaktionsmanagment ist bei FibPlus deutlich ausgeprägter. Zeos hat weniger, ist aber nach meinen eigenen Efahrungen bei kleineren Datenmengen schneller, bei großen Anfragen gleicht sich dies an. Grüße // Martin |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
SQLite ein.Die Embedded-Installation besteht darin, dass eine DLL-Datei (<350kb) ins Projektverzeichnis kopiert wird. Es gibt keine Lizenz. Das Projekt ist public domain und kann für alle Arten von Programmen benutzt werden. Es gibt einige Wrapper für Delphi.Zuletzt noch der Link zu einem Geschwindigkeitsvergleich. |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Ich möchte da auch mal
Blackfish SQL ins Rennen schicken ;-) |
Re: Firebird: Pro und Kontra oder auch Alternativen
Wir hatten Firebird in einem grösseren Projekt und einige Schwierigkeiten. Wir brauchten mehrere gleichzeitige DB Verbindungen in Threads zu Firebird und das gab massig probleme. Nach dem Wechsel auf Interbase wurde es besser aber gab immer noch Probleme.
Mit SQL Express läufts nun perfekt. Das waren keine Probleme von Firebird selbst, sondern von den Client Libraries. Da hatten wir unzähle versucht (DBX, IBX) etc und nichts lief wirklich perfekt. Ich bin froh, haben wir nun SQL Express. Auch da die DB einige Features bietet, welche Firebird nicht hat (CTE). |
Re: Firebird: Pro und Kontra oder auch Alternativen
Ihr hättet halt die richtigen Komponenten Testen sollen (IBDAC, FIBplus)
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Ich frag mich immer was andere so gerne falsch machen um den Firebird Server als lahme Gurke
zu verkaufen und das als Argument dafür zu bringen, das nur MS SQL und Oracle die Lösung aller Probleme sind. Eigentlich frag ich mich das aber nicht wirklich, denn ich hab fast täglich mit solchen Kandidaten zu tun und frag mich wirklich, welche Ignoranz man haben muss um so einen Schrott zu programmieren. Nun denn, meist bezahlen die Geld dafür das ich denen weiterhelfe. Wenn jeder so in Delphi programmieren würde wie ich das manchmal in der Datenbank sehe, dann könnte man auch sagen Delphi wäre schrott, mit Visual Studio geht das alles von alleine. Sehr lustig fand ich vor kurzem die Speicherung von Daten in TStringlist Lines bei denen sich in jeder Line wieder weiter TStringlists befinden, bei denen sich in jeder Line wieder weiter TStringlists befinden, usw .... Wenn man sich dann wundert das der Zugriff in so einer Baumstruktur via IndexOf grottenlahm ist, dem muss man leider erst mal ein paar Grundlagen erklären. In diversen Kreisen wagt man ja zu behaupten, das man mit Delphi ja eh nicht ernsthaft arbeiten kann, aber hier im Delphi Forum ist man damit eh auf dem Holzweg, zum Glück. Mal was aus der Praxis über Datenbankprojekte: Beispiel: Anwendung beim Kunden für viel Geld vom Softwarehaus gekauft, sobald die Software startet steht die älteste aktive Transaktion und das System wird immer langsamer (das Problem kennt nicht nur IB/FB). Kunde meckert beim Hersteller, Hersteller sagt, er sei nicht Schuld, das wäre die Datenbank, er soll doch von IB umstellen auf Oracle. Aktueller Wert für Insider: OAT 200.000, next 3.000.000 Wenn einen das nicht interessiert womit das zusammenhängt sollte man nicht Programmierer werden. Der Kunde ist auf jeden Fall ziemlich quakig, aber seit er von uns weiss das der Datenbankserver selbst nicht die Ursache ist, sondern ein ignoranter Softwarehersteller, weiss er jedenfalls, das es eine Lösung geben kann. Er muss halt nur noch mal seinen Softwarehersteller "überreden"! noch ein Beispiel: sehr großer Kunde programmiert Software auf Basis C++ und Postgresql selbst. Verarbeitung von täglich 50000 Anrufaufträgen über 150 ISDN parallele Leitungen in ingesamt 6 Linux Rechnern, ergibt insgesamt ca 600000 Operationen pro Monat. Das System bricht unter Last hoffnungslos zusammen und der Datenbankserver reagiert auf gar nichts mehr. Kunde fragt bei HK-Software ob man da nicht was machen könnte. Wir haben das System umgestellt auf Firebird und Phyton Scripte und es läuft wie erwartet. Die Umstellung der Datenbank war auch verbunden mit der Umstellung der Prozesse. Das Originalsystem hat in kleinen Testumgebungen immer gut funktioniert, aber unter echter Last reichte das eben nicht. Hier musste ein Webserver für Dateneingaben angebunden werden, einige anderen Schnittstellenprogramme liefen auch parallel. Postgresql hat keinen Superserver, ist also selbst für viele simultane Zugriffe auf db Ebene eher nicht geeignet, daher auch meist im Zusammenspiel mit irgendeiner Middleware bei größeren Installationen benutzbar. Viele glauben das das eine Stärke sei, das andere Server auch mit einer großen Anzahl an Connections keine Probleme hat wollen viele nicht glauben, weil die eigene favorisierte Plattform das eben nicht kann. Postgresql kommt bei der Garbage Collection zumindest bei diesen Anforderungen nicht mehr mit. Auf Basis Firebird geht das auch ohne den ganzen Adminquatsch (bitte mir jetzt nicht die 500 möglichen Parameter in Postgresql erklären). Vielleicht könnte Postgresql das auch leisten, es hat aber im Projekt die erforderlichen Leistungen nicht erbringen können. noch ein Beispiel: dpa System Volltextsuche läuft auf einem simplen Dualprozessor Dell Server, einige GB RAM (ich meine der hatte mal 15GB) und RAID PLatte. DB ist ca 30-40 GB groß, tagsüber arbeiten auf dieser Kiste ca 150 Redakteure gleichzeitig und es rödeln noch diverse Clients schreibend auf der DB, um neueste Meldungen aus aller Welt von allen möglichen Diensten in die DB zu schreiben. Insgeamt sind die Daten von 18 Monaten drin, ca 4 Millionen Dokumente. Ganz wichtige Frage für den Kunden: Wann hat die Volltextsuche die neuesten Daten im Index? Bei unserer Lösung auf Basis von Firebird und einem in Delphi geschriebenen Service werden die Daten via Eventalerter erkannt und umgehend in die globale Indextabelle eingetragen, stehen also dort nach dem Commit mit einem simplen containing Befehl zur Verfügung. Das macht auch google nicht ( mit zugegeben noch wesentlich mehr Daten, aber eben für diesen Kunden nicht sinnvoll einsetzbar). Die dpa ist extrem sensibel in Bezug auf Geschwindigkeit und auf Betriebssicherheit, denn wenn nachmittags für ca eine Stunde der Server ausfällt, dann sind am nächsten Tag die Zeitungen in Deutschland noch weniger lesenswert als sowieso schon. Der Server macht Volltextsuche und ist gleichzeitig DB Server für alle Clients. Fazit: Bei allen Lösungen macht es schon Sinn, das man sich mit den benutzten Werkzeugen auseinander setzt. Bei Datenbanken erwarten viele aufgrund der Austauschbarkeit durch die SQL Sprache einfach zu viel. Wenn man Leistung braucht bringt es nichts, einfach irgendein SQL auf Basis irgendeines gruseligen Datenmodells auszuführen und dann zu erwarten, das die gerade gewählte Plattform das gefälligst selbst optimieren soll. Wenn ich mir so anschaue was Kunden auch in Delphi schon verbrochen haben, dann erwartet man irgendwann eben nicht mehr so viel und ist um so mehr positiv überrascht wenn der Kunde sich doch schon intensiv mit Details seines Tuns auseinander setzt. Ich kann jedem aber glaubhaft versichern das bei entsprechender Programmierung der Firebird Server extrem gut skalierbar ist, von der simplen lokalen Anwendung als Embedded oder als 4*Quad Core Opteron (also 16 Kerne) unter Linux, so wie Björn das bei der Uni Erlangen demnächst testen will. Der Firebird Funktionsumfang ist auch allen Ebenen identisch und eine DB kann via Backup/Restore von jeder Plattform auf jede andere übertragen werden. Viele haben sich bei anderen Datenbanken von der Volltextsuche oft mehr versprochen (sofortige Verfügbarkeit neuer Daten im Index) oder auch bei der ggf. erforderlichen Replikation (Regelwerk und mitgelieferte Tools sind manchmal schwer durchschaubar). Und bei den Express Editions ist das oft gar nicht erst dabei. Wenn du dich auf eine Plattform festlegen willst kann ich dir ziemlich sicher bestätigen das es Firebird auch in diversen Jahren noch geben wird. Immerhin hatten wir auf der Firebird Konferenz letzte Woche in Hamburg fast 120 Leute da, davon einige Kernentwickler und sehr viele Inhaber von Softwarehäusern, die sehr großen Wert auf die weitere Entwicklung von Firebird legen und diese auch mit Geld nuterstützen, weil es sich eben rechnet. Gruß Holger |
Re: Firebird: Pro und Kontra oder auch Alternativen
Hallo zusammen,
mein Fazit zu diesem ausführlichen (und wie ich fand auch lehrreichen) Thema: - es gibt wie so oft im Leben "menschliche" Vorlieben und sachliche Argumente Ich werde mich endgültig auf Firebird festlegen. Zunächst einmal dann mit den Zeos Library Komponenten. Die Summe der Argumente und meine eigenen Vorstellungen (auch von den Kosten her) führten zu dieser Enstcheidung. Danke an alle für die vielen Infos und dem regen Meinungsaustausch! :thumb: |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Hallo,
ZEOS - falsch sehe ich auch so. Ein Umstieg auf eine anderes System ist sehr schwer. mit Query.Fields['Id'] war das glaube ich. Es gibt kein FieldByName().AsXXX. Zweiter Schwachpunkt ist das Fehlen von Hard-Commits, es werden nur SoftCommits (Commit Retaining) unterstützt, Ein HardCommit geht nur über das Beenden der Verbindung und Neuaufbau. Letzte Sache (für mich nicht so schlimm, aber für andere schon): Ein Connection kann nur eine Transaktion bedienen (wie bei der BDE). Heiko |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
Die Sache mit den fehlenden HardCommits und die fehlende Möglichkeit verschiedene Abfragen in verschiedene Transaktionen zu kapseln wiegt hier schwerer. |
Re: Firebird: Pro und Kontra oder auch Alternativen
Hallo,
ah stimmt, das war UIB, wo das nicht ging. Heiko |
Re: Firebird: Pro und Kontra oder auch Alternativen
Zitat:
www.da-soft.com |
Re: Firebird: Pro und Kontra oder auch Alternativen
Oder IBDAC, FIBplus
|
Re: Firebird: Pro und Kontra oder auch Alternativen
Hallo,
welche Komponenten nehme ich denn nun (für Firebird)? Bislang habe ich die eingebauten Interbase-Komponenten von D7 benutzt. Jetzt habe ich mir die UIB-Komponenten angeschaut. Eine Dokumentation gibt es wohl nicht?! |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 11:13 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz