FB auf einem Netzlaufwerk

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