Firebird Embedded

[Jens Hartmann]

Hallo und schönen Sontag zusammen,

ich habe mal eine Frage zu Firebird embedded. Momentan nutze ich die Firebird Datenbank für mein Programm. Ich bin jetzt mit meinem Programm soweit fertig, das ich eine Installatinonsroutine erstellen möchte, um die Beta Version einigen Leuten zur Verfügung stellen möchte um eventuelle Fehler zu lokalisieren.

Durch einen anderen Beitrag, bin ich aber vor ein paar Tagen auf das Theme Firebird embedded aufmerksam geworden. Da ich allerdings den ganzen unterschied noch nicht verstehen kann, bitte ich Euch mal um Erläuterung.

Momentan versteh ich das ganze so:

Normale Firebird, muss der Installationsroutine begefügt und mit Installiert werden, und wäre Server fähig.

Die embedded Version, kommt irgendwie mit dll´s aus und benötigt somit keine installation von Firebird, ist jedoch nur Einplatz tauglich. Was mir zum jetzigen Zeitpunkt völlig ausreichend wäre.

Vieleicht kann mir ja mal jemand die Vor und Nachteile erläutern, und gegebenenfalls die Vorgehensweise eine embedded Version zu nutzen.

Danke schon mal

Gruss Jens

[DeddyH]

Um Firebird Embedded zu betreiben, muss IIRC eine bestimmte Ordnerstruktur angelegt werden. Näheres dazu findest Du in der README_Embedded (ich glaube, die heißt so) Deines Firebird-Verzeichnisses.

[Balu der Bär]

Genau, bei der Embedded packst du einfach nur Dateien:
DB.FDB, fbclient.dll, firebird.conf, firebird.msg, ib_util.dll, icudt30.dll, icuin30.dll, icuuc30.dll mit ins Programmverzeichnis.

Enormer Vorteil: Es muss kein Dienst etc seperat installiert werden.

[Hansa]

Machs so rum : 1. FB embedded in leeres Verzeichnis installieren. Dann ist sichergestellt, dass wirklich alles dabei ist. 2. Packe alles von deinem Programm auch da rein. Mindestens also die EXE. Knackpunkt : das Programm geht von einem festen Ort aus, an dem irgendwas sein sollte. Dann vorher anpassen. Teste alles am besten mal mit USB-Stick, bevor einer der testen soll, noch demotiviert wird. :zwinker:

Edit : Vorgehensweise vom Bär könnte fehlerträchtig sein. Da fehlt schon mal das INTL Verzeichnis und das gäbe dann schon eventuell Ärger mit Zeichensätzen. Fange nur nicht an, da 100 Byte einsparen zu wollen !

[Jens Hartmann]

Zitat:

Zitat von Balu der Bär

Genau, bei der Embedded packst du einfach nur Dateien:
DB.FDB, fbclient.dll, firebird.conf, firebird.msg, ib_util.dll, icudt30.dll, icuin30.dll, icuuc30.dll mit ins Programmverzeichnis.

Soll also heißen, ich kann die selbe Datenbank verwenden, und muss meinem Install nur die oben gannanten Dateien anfügen.
Wie aber funktioniert das dann mit der Alias Adresse etc. Außerdem, kann ich die Embedded Version nicht als 2.1 finden.

Zitat:

Zitat von hansa

Machs so rum : 1. FB embedded in leeres Verzeichnis installieren. Dann ist sichergestellt, dass wirklich alles dabei ist. 2. Packe alles von deinem Programm auch da rein. Mindestens also die EXE. Knackpunkt : das Programm geht von einem festen Ort aus, an dem irgendwas sein sollte. Dann vorher anpassen. Teste alles am besten mal mit USB-Stick, bevor einer der testen soll, noch demotiviert wird.

"Fange nur nicht an, da 100 Byte einsparen zu wollen !"

Ne, an Speicherplatz soll es nicht scheitern. Mit geht es lediglich darum, Mein Programm ohne diesen Firebird Server(Dienst) auszuliefern.

Meine Datenbank, besteht aus 4 Tabellen und keinerlei Beziehungen zu einander. Es werden in der DB lediglich Daten gespeichert, die von einer Hardware erzeugt werden. Und daher dachte ich, wäre es besser und einfacher das ganze so zu lösen.

MFG

Jens

[omata]

Zitat:

Zitat von Jens Hartmann

Außerdem, kann ich die Embedded Version nicht als 2.1 finden.

klick

[Jens Hartmann]

Danke,

habe ich nicht gefunden.

MFG

Jens

[tsteinmaurer]

Hallo Jens,

einer meiner Firebird-Artikel aus dem Entwickler Magazin könnte hier vielleicht noch interessant sein, wenn es um Allgemeine Dinge des Embedded Servers geht.

http://blog.upscene.com/thomas/index...09&category=14

Ganz nach unten scrollen und Firebird Embedded Server öffnen.


lg,
Thomas
http://www.upscene.com

[Jens Hartmann]

Danke erstmal für die vielen antworten.

Ich fasse mal kurz zusammen, und hoffe das ich das Thema somit verstanden habe. Ich habe mir jetzt die Embedded Version wie...

"omate" gezeigt hat...
LINK

geladen und mal entpackt. Die Readme embedded gelesen und den Bericht von tsteinmaurer gelesen. Wenn ich das jetzt alles richtig verstanden habe, kann ich mit meinem Entwicklungssystem ersteinmal weiterarbeiten (Installierte Firebird). Sollte ich jetzt die Installationsroutine erstellen, packe ich den Inhalt der Enpackten Embedded mit in die Routine, so dass sich nachder Installation meine Anwendung und Datenbank und die Embedded im selben Verzeichniss befindet.

Nach der Installation müsste das ganze dann schon funktionieren. In meiner Komponente gebe ich als Datenbank Standort LOCALHOST:Alias an und in der aliases.conf dann den Standort der DB.

Fertig.

Ich hoffe das das alles so richtig ist.

MFG

Jens

[tsteinmaurer]

Hallo,

ja so in etwa paßt das. Du darfst allerdings nicht localhost:<alias> verwenden, weil durch das localhost die Embedded DLL nicht mehr als Server, sondern als Remote-Gateway (Client-DLL) verwendet wird. D.h. mit localhost wird versucht auf einen lokalen installierten Firebird auf Default-Port 3050 zu connecten, was fehlschlägt, wenn wirklich nur deine Distribution, also kein installierter Firebird Server vorhanden ist!

Im Connect-Pfad, einfach nur den Pfad zur Datenbank angeben. Kann auch nur das DB-File sein, wenn sich die EXE und das DB-File in deiner Distribution im selben Verzeichnis befinden.

[Jens Hartmann]

Zitat:

Zitat von tsteinmaurer

Im Connect-Pfad, einfach nur den Pfad zur Datenbank angeben. Kann auch nur das DB-File sein, wenn sich die EXE und das DB-File in deiner Distribution im selben Verzeichnis befinden.

Danke, das heißt doch dann für mich, das ich jede Version, die ich so ausliefern würde, definitiv nur Einplatzfähig wäre.

Folgerung:

Embedded Version = Auslieferung Einplatzversion
Firebird Server = Mehrplatzfähigkeit möglich.


MFG

Jens

[tsteinmaurer]

Hallo Jens,

genau das heißt es.

[neo4a]

Zitat:

Zitat von tsteinmaurer

genau das heißt es.

Vielleicht aber auch nicht ;). Die Einzel- oder Mehrplatzfähigkeit bestimmst Du mit der FB-Version, die Du aus Deiner Applikation ansprichst: Kannst Du Deine DB über einen installierten FB-Server ansprechen (ServerIP:c:\data\MeineDB.fdb), ist Dein Programm automatisch mehrplatzfähig; öffnest Du die DB per Connection-String jedoch exklusiv als Datei (c:\data\MeineDB.fdb), dann ist es halt "nur" ein Einzelplatzsystem.

Mit der Embedded-FB-Version kannst Du bei der Installation auf Zielsystemen eine DB-Umgebung mitliefern, die sich konfliktfrei und unabhängig von bereits installierten FB-Instanzen einrichten lässt: dann eben im Single-User-Betrieb.

Ich habe hier gezeigt, dass man auch eine Serverinstanz installationsfrei ausliefern kann. (Letztlich startet die App intern auch nur einen FB-Server im Applikation-Modus; ich habe das alles zusätzlich noch hoch komprimiert und unkaputtbar/manipulationsfrei in eine Exe gesteckt.) Hier reduziert sich dann das Risiko von Installationskonflikten lediglich auf die freie Portnummer bzw. Portfreigabe. Diese Lösung ist dann zwar kein Server-Dienst, aber dafür braucht es zum Start (ohne Installation) auch keine Admin-Berechtigung. Damit kann ich Mehrplatz-Applikationen ausliefern in Umgebungen, die mir ansonsten keinen administrativen Eingriff erlauben oder wo potentiell bereits andere FB-Versionen installiert sind.

--
Andreas

[tsteinmaurer]

Hallo,

nettes Proof-Of-Concept. :-D

D.h. aber auch, dass deine EXE zuerst einmal gestartet werden muss. Sei es durch den Benutzer oder erstmalig durch die darauf zugreifende Applikation. Bei der vom Firebird Projekt zur Verfügung gestellten Embedded Variante geschieht dies ja implizit durch das Laden der Embedded-DLL. Beide Konzepte haben für und wider, die ja bereits diskutiert wurden.

Keine Ahnung, ob deine Sache dann überhaupt noch etwas mit "Firebird" zu tun haben darf, oder ob du das z.B. AndiDB taufen mußt. :)

Seit Firebird 2.1 gibt es ja auch noch die Möglichkeit über instsvc mehrere Instanzen als Dienst zu installieren. Installation allerdings wieder mit Admin-Rechten. Geht prima mit der ZIP-Distribution. Theoretisch könnte der Inhalt der ZIP-Distribution in ein eigenes Setup-Skript mitreingepackt werden, mit entsprechendem Aufruf von instsvc.exe.

Ehrlich gesagt ist mir persönlich ein "Dedicated" installierter Dienst für ein RDBMS im Multi-User Betrieb lieber. Bzgl. Firebird Embedded ist auch noch zu sagen, dass mehrere Connections über den Prozess, der die fbembedded.dll geladen hat, ja möglich sind. D.h. Multi-Connection aus einem Prozess heraus geht ja.

Wie gesagt, interessantes Konzept, bitte nicht falsch verstehen.

[mkinzler]

Zudem da Verbesserungen in FB 3 zu erwarten sind; wenn diese mal kommt ( traditionell im Novemeber des aktuellen Jahres)

[tsteinmaurer]

Hallo Markus,

die Vergangenheit hat gezeigt, dass die angekündigten Release-Dates "unglaubwürdig" sind. Man braucht sich nur die Roadmap mit Stand Ende Dezember 2008 ansehen. Immer verspätet, bekommt man dann allerdings ein stabiles Produkt. Das kann ja auch was. :-D

[Balu der Bär]

Moin,

so verbindest du dich zur Embedded DB:

Delphi-Quellcode:

function TBdBDatabase.Connect: boolean;
begin
 with fConnection do
  begin
    Protocol := 'firebird-2.0';
    ReadOnly := false;
    User := 'SYSDBA';
    Password := 'masterkey';
    Database := ExtractFilePath(ParamStr(0)) + 'db.FDB';
    HostName := ''; 
    try
      Connect;
    except
     ...
    end;
    Result := Connected;
end;

[neo4a]

Zitat:

Zitat von tsteinmaurer

D.h. aber auch, dass deine EXE zuerst einmal gestartet werden muss. Sei es durch den Benutzer oder erstmalig durch die darauf zugreifende Applikation. Bei der vom Firebird Projekt zur Verfügung gestellten Embedded Variante geschieht dies ja implizit durch das Laden der Embedded-DLL.

Stimmt, (m)eine Applikation startet (implizit) den Serverprozess.

Zitat:

Zitat von tsteinmaurer

Keine Ahnung, ob deine Sache dann überhaupt noch etwas mit "Firebird" zu tun haben darf, oder ob du das z.B. AndiDB taufen mußt. :)

Ich nenne es halt "portabel" und nur dafür ist es gut: 4MB und ein Full-Featured-SQL-Server - das hat schon was ;)

--
Andreas

[Jens Hartmann]

Alles ganz interesant zu lesen,

aber ich denke in meinem Fall ist erstmal die Embedded Version ausreichend. Ich will zwar zu einem späteren Zeitpunkt eine Mehrplatzversion realisieren, aber ich denke ich sollte erstmal die Einplatzversion richtig fertig stellen.

Danke nochmal an alle und auch für die Interesanten Anregungen.

MFG

Jens

[neo4a]

Je nachdem, wie ernsthaft Du Deine App. entwickelst, möchte ich nur ganz leise anmerken, dass Mehrbenutzerfähigkeit per Design passiert. Das hat erst einmal nichts mit der verwendeten Firebird-Komponente zu tun. Es ist okay, wenn Du erst einmal die Anmeldung im Code erledigst und der Connection-String nur eine lokale DB zulässt (gerne auch mit FileOpen-Dialog), aber alle anderen Dinge (Verwendung von Transaktionen, Generatoren etc.) sollten von Anfang an so ausgelegt sein, dass *zeitgleich* mehrere User mit der DB arbeiten.

Dann ist der spätere Wechsel zwischen Single- und Multi-User-Betrieb nur ein Klacks.

--
Andreas

[Jens Hartmann]

Ich denke, das ich mich da an die Vorgaben von Firebird und ZEOS gehalten habe.

Mir geht es momentan nur darum, das ich die ersten Beta Versionen als Testobjekte laufen lassen möchte. Diese Rechner sind reine Einzelrechner und haben auch keinen Netzwerkzugang.

Es geht einfach erstmal um die Programmfunktion.

Die ganze weitere Entwicklung hängt dann sowieso vom Kunden ab. Das ich das Programm entwickelt habe, war Anfangs Spaß an der Freude. Das sich eine Kunde so ernsthaft dafür Interesiert, hätte ich nie gedacht.

Daher ist es erstmal Überhaupt Nebensache mit der Mehrplatzfähigkei, da der Kunde diese Anforderung nicht haben wird.

MFG

Jens

[tsteinmaurer]

Hallo Jens,

wie Andreas erwähnt hat, mußt du aber deine Anwendung auf jeden Fall mehrbenutzerfähig, mit einem gescheiten Transaktionskonzept, usw ... ausrüsten. Ich mach mir hiermit vermutlich keine Freunde, aber von Zeos würde ich mit Firebird lieber die Finger lassen (nichts gegen die Zeos Leute!), aber die fehlende Unterstützung von HARD COMMITs (also nur Soft Commits aka CommitRetaining), ohne hierbei die Connection schließen zu müssen, ist meiner Meinung nach ein NoGo.

[Jens Hartmann]

Hallo tsteinmaurer,

mein Problem zum jetzigen Zeitpunkt ist einfach erklaert. Momentan bin ich in keinem anderen Besitz einer Komponente. Ich habe auch momentan nicht darueber nachdedacht, weil ich zur Zeit noch nicht vor dem Problem stand. Ich habe sicherlich schon von FIBPlus und so gehoert Aber bis lang aus Kostengruenden noch nicht daran gedacht mir diese Komponente zu kaufen.

MFG

Jens

Zitat:

Zitat von tsteinmaurer

Hallo Jens,

wie Andreas erwähnt hat, mußt du aber deine Anwendung auf jeden Fall mehrbenutzerfähig, mit einem gescheiten Transaktionskonzept, usw ... ausrüsten. Ich mach mir hiermit vermutlich keine Freunde, aber von Zeos würde ich mit Firebird lieber die Finger lassen (nichts gegen die Zeos Leute!), aber die fehlende Unterstützung von HARD COMMITs (also nur Soft Commits aka CommitRetaining), ohne hierbei die Connection schließen zu müssen, ist meiner Meinung nach ein NoGo.

[DataCool]

Hi,

kurze Nachfrage, ist es möglich das ein Programm und einen Dienst(teilweise sogar mehrere Connections in Threads) beide auf die Embedded DB zugreifen ?
Denn wenn ich die Aussage über mir richtig deute darf NUR EIN PROZESS(Anzahl der Connections egal) auf die DB zugreifen.

Sehe ich das richtig ?

Greetz Data

[tsteinmaurer]

Hallo,

mit 2.1 und früher ja, mit 2.5 wird sich das ändern. Siehe auch mein FB 2.5 Architektur Comparison Sheet auf meinem Blog: http://blog.upscene.com/thomas/index...y091016-133211

[Chemiker]

Hallo,

Zitat:

Zitat von tsteinmaurer

aber die fehlende Unterstützung von HARD COMMITs (also nur Soft Commits aka CommitRetaining), ohne hierbei die Connection schließen zu müssen, ist meiner Meinung nach ein NoGo.

ich beschäftige mich jetzt schon eine ganze Weile mit der Transaktionssteuerung von Firebird, weil ich eine Anwendung habe die zwar kleine Datensätze in die Datenbank schreibt, dafür sind es am Tag ca. 300.000 Stück. Man kann förmlich zusehen wie der Server langsamer wird. Diese werden mit READ COMMITE abgeschlossen.
Jetzt habe ich irgendwo gelesen, dass bei Interbase(die Open Source Version woraus Firebird entstanden ist) ein READ COMMITE für den Server ständiger Stress bedeutet, angeblich muss dadurch die die Transaction Iventory Page aller Transaktionen jedes Mal neu zusammengestellt werden, wenn ein READ COMMITE verwendet wird.

Bis bald Chemiker

[mkinzler]

Wenn Transaktionen nicht hart commitet werden, leidet die Performance.

[Chemiker]

Hallo mkinzler,

das scheint bei Firebird/Interbase anders zu sein als bei anderen Datenbanken.

Bis bald Chemiker

[mkinzler]

Liegt an der Art und Weise wie Transaktionen implementiert sind. Statt einem Transaktionlog wird Datensatzversionierung verwendet

[hoika]

Hallo,

Zitat:

Jetzt habe ich irgendwo gelesen, dass bei Interbase(die Open Source Version woraus Firebird entstanden ist) ein READ COMMITE für den Server ständiger Stress bedeutet, angeblich muss dadurch die die Transaction Iventory Page aller Transaktionen jedes Mal neu zusammengestellt werden, wenn ein READ COMMITE verwendet wird.

Transaction Iventory Page - TIP

Fast richtig.
Jede neu erzeugte Transaktion bekommt eine Liste der "interessanten" Transaktionen mit,
nennen wir das mal so.
Irgendwann ist jede Transaktion uninteressant,
- wenn die diese erzeugt hat, (hard) committed ist
- es keine früheren Transaktionen mehr gibt
(die diese Trans. in der eigenen TIP haben)
jaja, so einfach ist es nicht, aber lassen wir das mal stehen

Bei einem SoftCommit wird aber die originale TIP kopiert und weiterverwendet.
Sind in der Zwischenzeit einige der sich dort befindlichen Transaktionen "uninteressant",
bleiben die trotzdem drin, wir haben ja kopiert,
statt eine neue TIP zu erzeugen.

das verballert
1. unnötig Speicher
2. muss die viel zu grosse TIP immer wieder (komplett) durchsucht werden

Das war mal vereinfacht.
Unter IBPhoenix.com kann man das sich auch komplizierter erklären lassen ;)
(Stichwort MGA, Multi Generation Architecture)

Die ZEOS nur SoftCommits kann (neue Version ist gerade raus, wie sieht es damit aus ???),
wird der Server mit der Zeit immer langsamer.
Es hilft dann nur ein Beenden aller Anwendungen (Disconnect/Connect reicht).
Abhilfe bei ZEOS ist z.B. bei jedem Form ein neues Connect zu machen.


Heiko

[Chemiker]

Hallo hoika,

mir geht es nicht um die ZEOS selber setze ich FIBPLus ein.

Ich denke ich muss mir ein Test Project mal schreiben, damit man das mal prüfen kann.
Bei 10.000.000 Datensätze ist das Problem nicht so gravierend, aber ab eine bestimmte Menge an Datensätze wird der Server immer langsamer.

Bis bald Chemiker

[tsteinmaurer]

Commit vs. CommitRetaining hat nicht wirklich was mit einem fehlenden Transaktionslog/MGA/Datensatzversionierung zu tun. CommitRetaining macht ein Commit behält allerdings den aktuellen Transaktions-Kontext inkl. der Transaction Inventory Page (TIP) usw ... bei. Dadurch, dass der Transaktionskontext nicht verloren geht, werden z.B. auch die Datenmengen nicht geschlossen. Gut zu sehen bei der Verwendung von datensensitiven Steuerelementen. CommitRetaining steht allerdings in einem direkten Zusammenhang mit schlechterer Performance, da dies die Transaktion quasi noch aktiv beläßt (da ja der Transaktionskontext nicht beendet wird => CURRENT_TRANSACTION ist z.B. auch noch die selbe ...). Dadurch kann auch die OAT nicht weiterlaufen und man bekommt bei ständiger Verwendung von CommitRetaining ein Performanceproblem (langlaufende Transaktion), da ja bei jedem Transaktionstart die Transaktion sich die aktuelle TIP merken muss usw. Wenn die OAT nicht weiterlaufen kann, kann dies die OIT natürlich auch nicht machen. Ein Sweepintervall hilft hir auch nicht, weil ja das Sweepintervall über OAT-OIT definiert ist. (das Thema schreit irgendwie nach einem Artikel *g*).

Darum, CommitRetaining bzw. Autocommit, da dies ja in der Regel CommitRetaining verwendet, mit Maßen genießen und die Transaktionen mit regelmäßigem Hard Commit beenden.

[hoika]

Hallo,

<Chemiker>
#26

aha.
Warum machst du ein ReadCommit ?

Ich würde entweder
1. nach dem kmopletten Import eine HardCommit machen
2. nach x Imports ein HardCommit


Thoams,
den Artikel gibt es doch schon ...
OK, nicht direkt zu CommitRetaining,
aber zu OAT-OIT.



"Index is out of date",
Das waren noch aussagekräftige Fehlermeldungen ;)


Heiko