FB auf einem Netzlaufwerk

[hoika]

Hallo,
folgender Kundenwunsch.
2 Rechner, beide sollen eine gemeinsame Datenbank benutzen.
Jeder Rechner kann ausgeschaltet sein.

Das geht natürlich nicht, aber:
Was ist, wenn ich ein freigegebenes USB-Laufwerk an einer Fritzbox habe?

Meines Erachtens geht das auch nicht.
Woher soll Rechner 2 wissen, dass auf Rechner 1 das Firebird den Zugriff hat
(und sich deshalb mit dem Firebird auf Rechner 1 verbinden soll und umgekehrt).

Was meint ihr?


Heiko

[Bambini]

Schon alleine aus Performance Gründen macht es sehr wenig Sinn die Datenbankdatei auf einem Netzwerklaufwerk zu haben.
Alle DB's brauche einen sehr schnellen Zugang zu ihren Dateien.

[Neutral General]

Du müsstest halt schon *etwas* haben wo sowohl die Datenbank als auch der Firebirdserver drauf sind und was dauerhaft läuft.

[4dk2]

Zitat:

Zitat von Bambini (Beitrag 1340952)

Schon alleine aus Performance Gründen macht es sehr wenig Sinn die Datenbankdatei auf einem Netzwerklaufwerk zu haben.
Alle DB's brauche einen sehr schnellen Zugang zu ihren Dateien.

Bei Zwei PCs, wird wohl keine "so" schnelle Anbindung benötigt.
Und ist auch heutzutage noch bei kleinen Systemen häufig zu finden (z.b. DBF, auch Netzlaufwerke)

Es hängt von dem Datenbank System an ob es Shared Files erlaubt/verwaltet.
Generell gehen tut es JA

Alternativ zu ner Fritzbox würde ich, aber nen NAS mit z.b. 2x Netzwerkport vorschlagen, aber auch nem Linux
mit SSH zugang, fall es beim SMb probleme gibt.
bei SharedFile DBs sind die SMB Parameter sehr variabel anpassbar.

[DeddyH]

Könnte man dann nicht gleich auf dem Linux den FB-Server installieren?

[hstreicher]

Firebird ist ein Server , wenn der auf 2 Rechnern laufen soll und immer mal der eine oder andere ausgeschaltet werden kann , dann
muss auf jedem PC der Server installiert werden , d.h. 2 Server laufen die auf eine FB Datenbank zugreifen und das geht !NICHT!

FB Braucht exclusiven Zugriff auf die Datei.

wenn die Geschwindigkeit zweitranig ist dann geht auf ein Raspberry als Microserver

http://mapopa.blogspot.de/2012/11/de...small-arm.html

und hier noch die Ofizielle Meinung dazu
http://www.firebirdfaq.org/faq46/

mfg Hannes

[hoika]

Hallo,
danke für die vielen Antworten.
Das hilft mir aber leider nicht weiter.

Das FB am einfachsten auf einem Server läuft, ist natürlich klar.

Aber die Anforderung ist nun mal so.

Der Kunde sagt: Bei dem anderen System geht das auch (z.B. DBase, Access auf Fritz-USB).

Heiko

[mikhal]

Schau dir mal die Spezifikation der Firebird embedded an, ich habe da so in Erinnerung, dass ab 2.5 mehrere embedded Clients auf eine Datenbank zugreifen können.

Grüße
Mikhal

[Sir Rufo]

@hoika

Ich schlage solchen Kunden dann immer vor, wenn die jetzt ihre Autos abschaffen und durch Tretroller ersetzen (damit kommt man auch von A nach B, günstiger im Unterhalt und für die Umwelt) dann bringe ich das System auch wie gewünscht zum Laufen.

Eine Optimierung muss man immer ganzheitlich umsetzen :stupid:

Seltsamerweise wollte sich bislang noch niemand auf diesen Deal einlassen :-D

[Bambini]

Zitat:

Zitat von mikhal (Beitrag 1340967)

Schau dir mal die Spezifikation der Firebird embedded an, ich habe da so in Erinnerung, dass ab 2.5 mehrere embedded Clients auf eine Datenbank zugreifen können.

Klappt leider nicht. Der "embedded" Client ist ja nur Client und Server zusammen. D.h. in der fbClient.dll ist alles drin und dieser locked die DB Datei exklusiv.

[Bambini]

Zitat:

Zitat von hoika (Beitrag 1340964)

Aber die Anforderung ist nun mal so.

Der Kunde sagt: Bei dem anderen System geht das auch (z.B. DBase, Access auf Fritz-USB).

... dann die Anwendung auf Access umbauen?

[p80286]

Zitat:

Zitat von Bambini (Beitrag 1340974)

Zitat:

Zitat von hoika (Beitrag 1340964)

Aber die Anforderung ist nun mal so.

Der Kunde sagt: Bei dem anderen System geht das auch (z.B. DBase, Access auf Fritz-USB).

... dann die Anwendung auf Access umbauen?

Statt Tretroller der Nachweis, daß man mit einem Fiat500 auch einen 5m3 Gastank transportieren kann:shock:

Wie wäre es anders herum. jeder Client bekommt eine eigene Datei und die beiden synchronisieren sich wenn sie nichts besseres zu tun haben.
Ich pers. halte von solchen Sachen recht wenig, aber Entscheider denken da wohl anders. Hätte den Charme, daß man sich da das Backup sparen könnte (-naja aber wer solche Anforderungen hat wird auch das mögen)

Gruß
K-H

[Bambini]

Zitat:

Zitat von 4dk2 (Beitrag 1340956)

Zitat:

Zitat von Bambini (Beitrag 1340952)

Schon alleine aus Performance Gründen macht es sehr wenig Sinn die Datenbankdatei auf einem Netzwerklaufwerk zu haben.
Alle DB's brauche einen sehr schnellen Zugang zu ihren Dateien.

Bei Zwei PCs, wird wohl keine "so" schnelle Anbindung benötigt.
Und ist auch heutzutage noch bei kleinen Systemen häufig zu finden (z.b. DBF, auch Netzlaufwerke)

Es hängt von dem Datenbank System an ob es Shared Files erlaubt/verwaltet.
Generell gehen tut es JA

Mit DB meine ich die Server gestützten. Die Client DB's wie DBF, Paradox, Access, FoxPro & Co., sind für Anwendungen mit größere Datenmengen und mehreren Users nicht geeignet.
Früher oder später stolpert da einer über das Netzwerkkabel oder der Rechner schmiert ab. Der Zustand der zurückgelassenen Dateien ist dann unbestimmt.

[Bernhard Geyer]

Zitat:

Zitat von Bambini (Beitrag 1340974)

Zitat:

Zitat von hoika (Beitrag 1340964)

Aber die Anforderung ist nun mal so.

Der Kunde sagt: Bei dem anderen System geht das auch (z.B. DBase, Access auf Fritz-USB).

... dann die Anwendung auf Access umbauen?

dBase? Kann man das überhaupt sinnvoll betreiben ohne das es immer Abschmiert
MS Access: Da gibts viele andere Probleme. So richtig ist das kein Vollwertiges DBMS welche die ACID-Forderungen erfüllt.

Wenn man Datenverlust und permanentes einspielen von Backups aktzeptiert kann man dBase und Access verwenden.
Sind die Daten wichtig, dann fallen beide DBMS raus.

[p80286]

Zitat:

Zitat von Bambini (Beitrag 1340977)

Früher oder später stolpert da einer über das Netzwerkkabel oder der Rechner schmiert ab. Der Zustand der zurückgelassenen Dateien ist dann unbestimmt.

Na und? das ist dann Heiko schuld, entweder hat er nicht hinreichend auf diese Problematik hingewiesen, oder er hat sie hinter einem Wust von Fachbegriffen versteckt oder ......

Gruß
K-H

Zitat:

Zitat von Bernhard Geyer (Beitrag 1340979)

Wenn man Datenverlust und permanentes einspielen von Backups aktzeptiert kann man dBase und Access verwenden.
Sind die Daten wichtig, dann fallen beide DBMS raus.

Das zeigt doch nur, daß Du keine Ahnung hast, die Mitgliederverwaltung unseres Kaninchenzüchtervereins funktioniert seit 30 Jahren damit!

[Bambini]

Zitat:

Zitat von p80286 (Beitrag 1340980)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1340979)

Wenn man Datenverlust und permanentes einspielen von Backups aktzeptiert kann man dBase und Access verwenden.
Sind die Daten wichtig, dann fallen beide DBMS raus.

Das zeigt doch nur, daß Du keine Ahnung hast, die Mitgliederverwaltung unseres Kaninchenzüchtervereins funktioniert seit 30 Jahren damit!

Wow, dass ist dann noch mit Textzeichen und blickendem Cursor. Vielleicht noch mit Clipper gebaut? Hat die das Wort Netzwerk schon einmal gehört?

[p80286]

Zitat:

Zitat von Bambini (Beitrag 1340981)

Wow, dass ist dann noch mit Textzeichen und blickendem Cursor. Vielleicht noch mit Clipper gebaut? Hat die das Wort Netzwerk schon einmal gehört?

:thumb:na klar alles mit 10base2 realisiert, überhaupt kein Problem!

(noch 4 Stunden, dann ist WE)
Gruß
K-H

[mkinzler]

Zitat:

Zitat von Bambini (Beitrag 1340972)

Zitat:

Zitat von mikhal (Beitrag 1340967)

Schau dir mal die Spezifikation der Firebird embedded an, ich habe da so in Erinnerung, dass ab 2.5 mehrere embedded Clients auf eine Datenbank zugreifen können.

Klappt leider nicht. Der "embedded" Client ist ja nur Client und Server zusammen. D.h. in der fbClient.dll ist alles drin und dieser locked die DB Datei exklusiv.

Nein seit Firebird 2.5 basiert der embedded (Server) Client auf SuperClassic und nicht mehr SuperServer.

[Bambini]

Zitat:

Zitat von p80286 (Beitrag 1340983)

Zitat:

Zitat von Bambini (Beitrag 1340981)

Wow, dass ist dann noch mit Textzeichen und blickendem Cursor. Vielleicht noch mit Clipper gebaut? Hat die das Wort Netzwerk schon einmal gehört?

:thumb:na klar alles mit 10base2 realisiert, überhaupt kein Problem!

... auch das mit den Lochkarten, hat alles prima geklappt. Verstehe heute immer noch nicht, warum es die nicht mehr gibt;-)

[mkinzler]

Der bessere Weg, wäre ein NAS, auf welchem der Server installiert ist. Auf einer FritzBox wird das nicht funktionieren. Zudem ist diese von sich aus schon wenig performant ( als NAS) und dann noch von einem externen Laufwerk.

[Bambini]

Zitat:

Zitat von mkinzler (Beitrag 1340985)

Zitat:

Zitat von Bambini (Beitrag 1340972)

Zitat:

Zitat von mikhal (Beitrag 1340967)

Schau dir mal die Spezifikation der Firebird embedded an, ich habe da so in Erinnerung, dass ab 2.5 mehrere embedded Clients auf eine Datenbank zugreifen können.

Klappt leider nicht. Der "embedded" Client ist ja nur Client und Server zusammen. D.h. in der fbClient.dll ist alles drin und dieser locked die DB Datei exklusiv.

Nein seit Firebird 2.5 basiert der embedded (Server) Client auf SuperClassic und nicht mehr SuperServer.

Ist denn der SuperClassic nicht: Ein Prozess pro Client?
Was startet denn da als Prozess bei der embedded Version, die fbClient.dll?

[mkinzler]

Zitat:

Zitat von Bambini (Beitrag 1340989)

Zitat:

Zitat von mkinzler (Beitrag 1340985)

Zitat:

Zitat von Bambini (Beitrag 1340972)

Zitat:

Zitat von mikhal (Beitrag 1340967)

Schau dir mal die Spezifikation der Firebird embedded an, ich habe da so in Erinnerung, dass ab 2.5 mehrere embedded Clients auf eine Datenbank zugreifen können.

Klappt leider nicht. Der "embedded" Client ist ja nur Client und Server zusammen. D.h. in der fbClient.dll ist alles drin und dieser locked die DB Datei exklusiv.

Nein seit Firebird 2.5 basiert der embedded (Server) Client auf SuperClassic und nicht mehr SuperServer.

Ist denn der SuperClassic nicht: Ein Prozess pro Client?
Was startet denn da als Prozess bei der embedded Version, die fbClient.dll?

Ein Task pro Verbindung (mehrere Threads). Es können aber mehrere Prozesse ( in diesem Fall auf verscheidenen Rechner) auf die selbe Datei zugreifen.

[Rollo62]

Bescheuerte Anforderung :shock:

Replikation kommt natürlich nicht in Frage, oder doch ?

Ich frage in solchen Fällen immer: Was ist eigentlich der Zweck ?

Rollo

[Bambini]

Zitat:

Zitat von mkinzler (Beitrag 1340991)

Ein Task pro Verbindung (mehrere Threads). Es können aber mehrere Prozesse ( in diesem Fall auf verscheidenen Rechner) auf die selbe Datei zugreifen.

hört sich tollkühn an, dass jeder Prozess die Datei schreibt. Wenn das auch Rechner übergreifend geschrieben wird, dann sind wir wieder bei DBF & Co.
Ein kurzer Test auf eine vom FB 2.5 embedded geöffnete DB Datei -> Zugriff verweigert.

Nachtrag: Das würde ja auch voraussetzen, das jeder der FB alle seine Änderung in die Datei pflegen muss und nix cachen kann/darf.

[Blup]

Was funktionieren könnte:
Auf beiden PC wird der Server installiert. Der Client versucht zuerst die Datenbank mit dem eigenen Server zu öffnen.
Schlägt das fehl, versucht er das mit dem Server auf dem jeweils anderen PC.
Dafür darf deine Software aber keine Transaktionen offen halten. Wird z.B. beim Speichern von Daten der andere PC heruntergefahren, muss deine Software auf den eigenen Server umschalten und alle Aktionen der Transaktion wiederholen. Deine Software sollte in jeder Situation in der Lage sein umzuschalten, ohne die Arbeit des Anwenders zu unterbechen.

Aber eigentlich solltest du die Anforderung deines Kunden nicht einfach so hinnehmen. Das wichtigste ist Fragen zu stellen und zuzuhören. Warum hat er diese Anforderung und was will er auf diesem Weg erreichen?

[sh17]

Warum hat hier noch keiner "Cloud-Server" in die Runde geworfen? 2 Rechner die immer mal aus sind, eine Fritzbox = Internetzugang. Und Aufgrund der Anforderung des Kunden können die Datenmengen auch nicht gewaltig sein. :duck:

[Neumann]

Man kann es vielleicht hinbekommen, das jeder PC mit eigener Datenbank läuft und einen Datenabgleich realisieren. Ist aber aufwendig und es gibt viele mögliche Probleme. Z.B. Auf PC A werden Artikel angelegt, PC B ist aus. Morgen wird PC B angeschaltet, PC A ist aus. Also gibt es die neuen Artikel nicht auf B. Man braucht also noch C über den der Austausch läuft und der immer an ist, wenn A oder B in Betrieb sind.

Man kann die Sache noch weiter durchdenken aber es wird immer kompliziert und es lauern Fehlerquellen.

Das Einfachste ist, die Datenbank auf A zu legen und wenn man B benutzen will A eben einzuschalten.

[Sir Rufo]

Man muss bei so etwas doch einfach nur rechnen.

Ein Server der die FB Datenbank hostet liegt so um die 500€ zzgl. 500€ für Installation und Unerwartetes.
(Minimal-Hardware)

Kann man die Entwicklung von so einem Abgleich-Szenario oder eben anderer Alternativen für genau diese 1000€ darstellen?

Die Einschätzung muss jeder selber treffen und dann dem Kunden die Preise mitteilen.

Inkl. Server kostet der ganze Rutsch 11.000€
Ohne Server kostet der ganze Rutsch 13.000€

Treffen Sie ihre Entscheidung.

Die meisten Entscheider die ich kenne, sind nicht umbedingt computer-affin, können aber rechnen und Entscheidungen treffen.

[Chemiker]

Hallo hoika,

einen ähnlichen Fall hatte ich auch mal vor Jahren. Ich habe gefragt welcher Rechner am längsten am Tag läuft und diesen dann zum FB-Server gemacht und das Organisatorisch so gelöst, dass der Rechner mit dem Server immer vor den anderen Rechner laufen muss und nach Büroschluss als letzter heruntergefahren wird.

Alle anderen Lösungen, die nicht auf Hardware oder eine Cloud Erweiterung hinauslaufen sind meiner Meinung nicht zielführend.

Bis bald Chemiker

[mm1256]

Interessanter Thread und interessante Antworten.

Zitat:

Zitat von hoika (Beitrag 1340964)

Aber die Anforderung ist nun mal so.

Der Kunde sagt: Bei dem anderen System geht das auch (z.B. DBase, Access auf Fritz-USB).

Damit wurde die Frage doch bereits in #7 beantwortet: FB ist für diese Anforderung die falsche Datenbank.

Hinzu kommt: Wenn es mit einem anderen System offensichtlich funktioniert, dann können die Anforderungen hinsichtlich Performance und Datenmenge wohl nicht so hoch sein.

Ob die Anforderung - und in Folge davon die Realisierung des Projektes mit einer dieser Datenbanken - Sinn macht oder nicht, muss letztendlich der Kunde entscheiden, nachdem ihm alle Fakten verständlich dargelegt wurden. Das ist die eigentliche Herausforderung.

[dummzeuch]

Nur, um es mal erwähnt zu haben:

Solange nur lesend zugegriffen wird, ist es sehr wohl möglich eine Firebird-Datenbank auf einen Netzwerk-Share zu legen und von mehreren Firebird embedded Engines darauf zuzugreifen:

http://delphi.wikia.com/wiki/Firebird_tipps

Ob das in diesem Fall die Lösung ist, wage ich aber zu bezweifeln.

[p80286]

Zitat:

Zitat von mm1256 (Beitrag 1341159)

Ob die Anforderung - und in Folge davon die Realisierung des Projektes mit einer dieser Datenbanken - Sinn macht oder nicht, muss letztendlich der Kunde entscheiden, nachdem ihm alle Fakten verständlich dargelegt wurden. Das ist die eigentliche Herausforderung.

Wie war! Aber wie argumentiert man gegen "mein Sohn hat das bei uns zu Hause auch so realisiert"? Wenn ich so etwas höre, habe ich das Gefühl im falschen Film zu sein. Bei Nachfragen ist der Sohn dann auch meistens nicht erreichbar.

Gruß
K-H

[Sir Rufo]

Die Antwort darauf ergibt sich aus dem konkreten Kontext (dem Geschäftsfeld) des Kunden.

Da lassen sich immer Analogien finden, wo der Kunde eben auch nichts einsetzt, was für den Hausgebrauch zwar ausreicht aber eben nicht für den professionellen Einsatz.

Wenn der Kunde aber generell nicht so auf Zuverlässigkeit steht, dann ist das meist übergreifend und wirkt sich auch auf die Zahlungsmoral aus -> auch nicht zuverlässig.

Den braucht man dann nicht und empfiehlt ihm, das doch von seinem Sohn umsetzen zu lassen.

[hoika]

Hallo,
danke für die vielen Antworten.
Bei tausend Kunden läuft es mit einem Firebird-Server.
Nur wegen dem einen Kunden stellen wir weder die DB um, noch fangen wir an mit Replikation oder Bastellösungen.

Der Classic oder SuperClassic dürfte nicht mit mehreren Rechner funktionieren,
weil die Prozesse sich untereinander synchronisieren.
Das passiert AFAIK direkt im Speicher und nicht in der DB selbst.
In der Firebird.Conf sind ja entsprechende Optionen (z.B. LockMemSize, LockSemCount).

Und hier http://firebirdsql.org/manual/qsg25-installing.html steht
Firebird server – and any databases you create or connect to – must reside on a hard drive that is physically connected to the host machine. You cannot locate components of the server, or any database, on a mapped drive, a filesystem share or a network filesystem.

Wenn er das nicht will, haben wir halt einen Kunden, aber auch ein Problem weniger ...