[Firebird] Minimum Client

[MrSpock]

Hallo,

für die Version 2.x des Firebird Servers gibt es ja keine ClientInstall Routine mehr. Und es genügt die minimale Client Installation durchzuführen.

Meine Frage ist, weiß jemand welche Fehlermeldung der Client bringt, wenn die Visual Studio runtime files, die in dem oben verlinkten Beitrag aufgelistet werden, fehlen?

[RWarnecke]

Meines Wissens reicht es, wenn Du die Embedded Version von dieser Seite herunterlädst und den Inhalt mit ins Programmverzeichnis stellst. Für den Serverzugriff einfach noch die fbembed.dll nach fbclient.dll umbenennen.

[pmoegenb]

Zitat:

Zitat von RWarnecke (Beitrag 1252837)

Für den Serverzugriff einfach noch die fbembed.dll nach fbclient.dll umbenennen.

Kann ich mir nicht vorstellen.

In der 32-bit-Variante:

fbclient.dll = 540 KB
fbembed.dll = 3.712 KB

[mkinzler]

WEnn man kein lokales Protokoll, also nur über IP verbindet, kann man den embedded nehmen. Die Dll hat halt dann auch den Server "im Bauch".

[MrSpock]

Ich dachte, die embedded Version kann nur auf localhost zugreifen!?

Hintergrund meiner Frage ist folgender:

Ich habe eine Firebird Anwendung, die im Netzwerk liegt. Die gds32.dll liegt im Programmverzeichnis. Die meisten Rechner in dem Netzwerk (Win 7, 64 Bit) können problemlos auf die DB zugreifen.

2 neu eingerichtete Win 7 Rechner melden den Fehler:

Zitat:

failed to establish a connection

. Sie versuchen auch über die gds32.dll zuzugreifen, denn als ich diese umbenannt habe, kam sinngemäß die Meldung "gds32.dll nicht gefunden".

Jetzt wollte ich halt wissen, ob das Fehlen der runtime Dateien auf den neu eingerichteten Rechnern eventuell die Ursache sein könnten. :stupid:

[mkinzler]

Zitat:

Ich dachte, die embedded Version kann nur auf localhost zugreifen!?

Nein. Bei Netzwerkzugriff verhält er sich wie der "normale" Client. Bei Zugriff über lokales Protokoll, greift er nicht auf einen externer Serverdienst zu, sondern verwendet eine eigene "interne" Serverinstanz.
Schau Dir die Client-Dll mal mit dem dependancy viewer an, dann siehst Du welche andere Dlls referenziert/geladen werden.

[Lemmy]

wichtig bei Firebird ist im Grunde nur der verwendete ConnectionString *):

mit der Embedded.DLL und einem lokalen Pfad (c:\....) funktioniert die als lokaler embedded Server. Mit einem TCP-Zugriffspfad (server:c:\...) aber als einfacher Client - wobei dann auf dem Server aber auch eine Server-Instanz laufen muss.

Deshalb würde ich auch "nie" einen Embedded-Server als Client verwenden, wenn die Anwender am Verbindungspfad rumspielen dürfen, das kann nur schief gehen - wenn auf dem Server mit der embedded-DLL mit einem lokalen Zugriffspfad eine Verbindung hergestellt wird, dann kann selbstverständlich niemand anders, insbesondere nicht der eigentliche laufende Server auf die Datenbank verbinden!

Anmerkung: WObei mit der reinen Client.dll (ca. 300 kByte) auch über einen lokalen ConnectionString keine Verbindung aufgebaut werden, wenn nicht ein Server läuft.

[RWarnecke]

Hallo Lemmy,

Deinen Beitrag verstehe ich irgendwie nicht ganz.

Ich versuche es mal anhand eines Beispiels zu erklären, wie ich es immer mache. Auf Rechner A setze ich ganz normal einen Super- oder Classic Firebird Server auf, der als Dienst konfiguriert ist. Dabei ist es egal ob Windows oder Linux als Betriebssystem dient. Dann gehe ich an den Client und nehme die Dateien von Embedded-Version, kopiere diese in mein Verzeichnis, benenne die Datei fbembed.dll in fbclient.dll um und und starte dann mein Programm. Ist jetzt der richtige Server und Datenbankpfad hinterlegt funktioniert die Verbindung wunderbar, auch mit mehreren Geräten.

So habe ich es bei Code-Orakel gemacht und mache es auch aktuell für ein Kundenprojekt so. Warum sollte ich hier eine andere Client-DLL nehmen ? :gruebel:

[Lemmy]

Hi,

solange Server und CLient wirklich getrennt sind ist das Risiko nicht gegeben - das ist nur dann der Fall, wenn der Server auch gleichzeitig als Client fungiert sprich die Anwendungssoftware installiert ist.

[RWarnecke]

Ok, danke. Dann habe ich es jetzt verstanden.