Firebird Embedded

[Jens Hartmann]

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 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.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.

[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 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 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