firebird embedded und paralleler Zugriff

[khh]

ich mach mal hierzu nen neuen Tread auf.

Der embedded Server in der Version 2.1.4X funktioniert, nach ein paar Einstellungsschwierigkeiten meinerseits, jetzt mit Zeos 6.6 fehlerlos.
Allerdings ist nur jeweils ein exklusiver Zugriff auf die DB möglich :-(
(Ich hab da im Hinterkopf das ist da so :( )
Der gleichzeitige Versuch von einem 2ten Programm auf die DB zuzugreifen bringt ne sql-error " der Prozess kann nicht...."
Gibts ne Möglichkeit mehrfach gleichzeitig auf die DB zuzugreifen, oder ist da die embedded-version doch nicht das Gelbe vom Ei ?


Danke gruss KHH

[mkinzler]

Das funktioniert erst ab 2.5. Grundsätzlich würde ich für Multiuser-Zugriff aber eine Servervariante einsetzen ( und dies unabhängig vom verwendetem DBMS)

[grl]

Gleichzeitig mit der 2.1er embedded geht definitiv nicht.

Mit der 2.5er solls gehen (es sollte sich auch problemlos die 2.1er durch die 2.5er ersetzen lassen). Weiß aber nicht wie stabil das ist - wir haben hier einige freezes, von denen wir aber noch nicht wissen ob sie an unserer Software oder an der Firbird-Embedded-Engine liegen...

Gruß
Luggi

[khh]

Zitat:

Zitat von grl (Beitrag 1172385)

es sollte sich auch problemlos die 2.1er durch die 2.5er ersetzen lassen
Gruß
Luggi

leider nicht

zeos in der Version 6.6 macht da nicht mit :-(

[mkinzler]

Und Zeos7 ?

[khh]

zeos 7 hab ich noch nicht installiert.
Wäre ne Überlegung wert, wenn sich das Upgrade auf 7 auch sonst lohnt.
Nur wg dem embedded Server möchte ich ungern die Gefahr eingehen , dass es sonst welche Ungereimtheiten gibt.

[QuickAndDirty]

Ich würde grundsätzlich niemals mehrer Programme auf der selben Datenbank(Edit: nezieht sich auf die FB embeded und Filebasierte Datenbanken) arbeiten lassen und auch verhindern das mehrer Instanzen eines Programmes das tun. Diesen quatsch kennt man ja von Paradox und Jet-Engine. Die Idee soetwas zu machen scheitert einfach am Windows-Dateisystem (OpLocks).

Die beste Lösung für einen Embedded SQL Server ist es so ähnlich wie MSSQL Server Express Embedded vorzughen. Das erste Programm das zu dieser Datenbank connecten will startet den Server wenn es keinen findet der läuft. Wenn keine Conection mehr da ist beendet sich der Server nach einiger zeit.

[khh]

Zitat:

Zitat von QuickAndDirty (Beitrag 1172422)

Ich würde grundsätzlich niemals mehrer Programme auf der selben Datenbank arbeiten lassen

und was machst du in Mehrbenutzerumgebungen ?

[rweinzierl]

Hallo

Bei nur lesendem Zugriff geht auch die embedded Version.
Einfach die Datenbank auf schreibgeschützt setzten (sowohl read only in der Datenbank als auch den Schreibschutz von Windows)

Dann können beliebig viele Programme gleichzeitig zugreifen.


mfg

Reinhold

[mkinzler]

Zitat:

Zitat von khh (Beitrag 1172423)

Zitat:

Zitat von QuickAndDirty (Beitrag 1172422)

Ich würde grundsätzlich niemals mehrer Programme auf der selben Datenbank arbeiten lassen

und was machst du in Mehrbenutzerumgebungen ?

Einen Server verwenden.

[khh]

Zitat:

Zitat von mkinzler (Beitrag 1172425)

Zitat:

Zitat von khh (Beitrag 1172423)

Zitat:

Zitat von QuickAndDirty (Beitrag 1172422)

Ich würde grundsätzlich niemals mehrer Programme auf der selben Datenbank arbeiten lassen

und was machst du in Mehrbenutzerumgebungen ?

Einen Server verwenden.

das ja sowiso
das widerspricht aber der Aussage "niemals mehrere Prog..."
oder bezog sich das nur auf die embedded Versionen ?

[mkinzler]

Ich habe das so verstanden das er die embedded meint ( direkter Zugriff mehrerer Programme auf die Datenbankdatei)

[blackfin]

Man braucht keinen Server für multi-Zugriff auf die Firebird 2.5, die embedded kann das genauso gut.
(das ist ja eines der Features, die extra dafür in der 2.5er embedded implementiert wurden)
Edit und Korrektur (falls jemand nicht weiterliest): Das gilt, solange die gleichzeitigen Zugriffe auf einem Host sind.

Meiner Meinung nach liegt das Problem nicht an FB, sondern an Zeos. Ich hatte mit den Komponenten ähnliche Probleme und bin froh, sie nicht mehr verwenden zu müssen.
Es wäre meiner Meinung nach die beste Möglichkeit, Zeos wegzuschmeissen und vernünftige Zugriffskomponenten zu nehmen, die nicht an allen Ecken und Enden Probleme machen.
Zeos, vor allem die 7, ist leider buggy ohne Ende. Ich wollte zuerst auch von Zeos 6 auf Zeos 7 updaten, die Probleme mit Geschwindigkeit, Unicode und seltsamen Fehlern insgesamt von Zeos haben mich dann dazu bewegt, UniDac zu kaufen...und ich habs bisher nicht bereut, im Gegenteil.
Andere schwören auch auf IBDAC oder UIB.

[khh]

Zitat:

Zitat von mkinzler (Beitrag 1172428)

Ich habe das so verstanden das er die embedded meint ( direkter Zugriff mehrerer Programme auf die Datenbankdatei)

ok dann passt das ja

[Morphie]

Kann ich bestätigen... Mit Zeos hatte ich nur Probleme... Ich dachte schon ich wär einfach zu doof dafür... Habe dann IBDac ausprobiert und hatte keinerlei Probleme mehr.

[QuickAndDirty]

Zitat:

Zitat von khh (Beitrag 1172423)

Zitat:

Zitat von QuickAndDirty (Beitrag 1172422)

Ich würde grundsätzlich niemals mehrer Programme auf der selben Datenbank arbeiten lassen

und was machst du in Mehrbenutzerumgebungen ?

Wie MKinzler schon sagte sollte man dann über einen Server gehen
und wenn es nur ein SQL Server ist,
aber so direkt auf Dateien sollte man nie mit mehreren
Programmen gleichzeitig arbeiten!
Windows bekommt das einfach nicht hin!
Und es gibt auf dieser Erde keine Datenbank die mehrere Programme direkt auf einer Datei arbeiten lässt
, das ganze unter Windows und dabei garantiert das bei Schreiboperationen keine Datenverluste auftreten.
In Paradox hatte man dadurch regelmässig beschädigte Schlüssel und in der JET Engine ganze Datenbanken die man aus der Datensicherung zurrückladen musste. Und diese beiden haben das echt laaaange versucht. Mit z.b. eigenem locking (eigentlich müsste das windows locking ausreichen!) usw.
aber es geht einfach nicht.

[himitsu]

Zitat:

Man braucht keinen Server für multi-Zugriff auf die Firebird 2.5, die embedded kann das genauso gut.
(das ist ja eines der Features, die extra dafür in der 2.5er embedded implementiert wurden)

Und wie wird das mit der Cache gehandhabt?
Oder gleichzeitige Schreibzugriffe, bzw. woher wissen sie ob jemand Anderes was verändert hat usw.

Unterhalten sich dann die Programme miteinander?
Geht natürlich nicht unbedingt, wenn die eine Datei auf 'nem Netzlaufwerk nutzen und die Programme keine Verbindung aufbauen können, bzw. sie eh nix voneinander wissen.


Bei einem ReadOnly-Zugriff ist das alles ja kein Problem, aber sonst stell ich mir das eher schwer vor.

[blackfin]

Zitat:

Geht natürlich nicht unbedingt, wenn die eine Datei auf 'nem Netzlaufwerk nutzen und die Programme keine Verbindung aufbauen können, bzw. sie eh nix voneinander wissen.

Das ist richtig, wenn es verschiedene Hosts sind, braucht man einen Server.
Mehrere Programmzugriffe gleichzeitig auf einem Host geht allerdings, dort gibt es in der FB 2.5 einen globalen, internen Lockmechanismus / Locktable der das regelt.
Zugriffe über ein Netzlaufwerk sind ein "No-Go" beim FB embedded, steht glaube ich sogar im Manual.

Ich wüsste nun aber keine embedded-Datenbank, die concurrent writes ohne manuelles Locking ermöglicht...SQLite kann das ja AFAIK ohne Locking auch nicht.
(allerdings bin ich jetzt auch nicht so der Mensch, der alle embedded-Datenbanken auswendig kennt :-D)

[p80286]

Zitat:

Zitat von QuickAndDirty (Beitrag 1172513)

.., das ganze unter Windows und dabei garantiert das bei Schreiboperationen keine Datenverluste auftreten.

Das kann man so pauschal nicht stehen lassen.
Unsere Oracle-DB werden auf Windows-Servern gehostet, und es gibt keine Datenverluste. Es ist eher ein Problem der DB und nicht des OS.

(war da eben die rede von ACCESS und PARADOX im Zusammenhang mit Datenbanken????)

Gruß
K-H

[QuickAndDirty]

Zitat:

Zitat von p80286 (Beitrag 1172553)

Zitat:

Zitat von QuickAndDirty (Beitrag 1172513)

.., das ganze unter Windows und dabei garantiert das bei Schreiboperationen keine Datenverluste auftreten.

Das kann man so pauschal nicht stehen lassen.
Unsere Oracle-DB werden auf Windows-Servern gehostet, und es gibt keine Datenverluste. Es ist eher ein Problem der DB und nicht des OS.

(war da eben die rede von ACCESS und PARADOX im Zusammenhang mit Datenbanken????)

Gruß
K-H

Ich rede nicht von SQL Servern sondern von Filebasierten Datenbanken. Bei Oracle greift nur ein Programm auf die Datenbankdateien zu! und das ist der Oracle SQL Server.
Und ja Paradox und Jet sind Datenbanken und DBISAM, DBASE, INFORMIX, FOXPRO &c.

[QuickAndDirty]

Zitat:

Zitat von blackfin (Beitrag 1172548)

Zitat:

Geht natürlich nicht unbedingt, wenn die eine Datei auf 'nem Netzlaufwerk nutzen und die Programme keine Verbindung aufbauen können, bzw. sie eh nix voneinander wissen.

Das ist richtig, wenn es verschiedene Hosts sind, braucht man einen Server.
Mehrere Programmzugriffe gleichzeitig auf einem Host geht allerdings, dort gibt es in der FB 2.5 einen globalen, internen Lockmechanismus / Locktable der das regelt.
Zugriffe über ein Netzlaufwerk sind ein "No-Go" beim FB embedded, steht glaube ich sogar im Manual.

Ich wüsste nun aber keine embedded-Datenbank, die concurrent writes ohne manuelles Locking ermöglicht...SQLite kann das ja AFAIK ohne Locking auch nicht.
(allerdings bin ich jetzt auch nicht so der Mensch, der alle embedded-Datenbanken auswendig kennt :-D)

Auf einem Rechner kann das gehen. Was passiert mit den gelockten Datensätzen wenn ein Programm vor dem Unlock abstürzt? Machen die das mit 'nem Haltbarkeitsdatum für ein locking, oder zieht ein Programm dann alle mit in den Tod?

[blackfin]

Gute Frage!! Mal ausprobieren...geht über studieren. Allerdings hatte ich beim FB embedded bei abstürzenden Programmen bisher noch nie Probleme mit Locks.
(und ich habe die Programme schon oft durch Programmfehler in der Entwicklungsphase abstürzen lassen..)

Ich weiss allerdings nicht, wie die das intern machen...leider gibt es da kaum interne Specs, da die Tech-Spezifikationen der Webseite immer noch auf dem Stand der 2.0 sind und auch darauf hingewiesen wird, dass die Dokus etwas hinterherhinken.
(kann gut sein, dass es irgendwo versteckt ist, aber die Seite ist leider eh nicht sonderlich übersichtlich...schade eigentlich, FB ist so eine gute Datenbank..)
Würde mich selbst sehr interessieren, wie die neue Embedded-Superclassic-Architektur des 2.5 intern genau funktioniert.
Beim Client-/Server-Modell ist es ja klar, da ein Prozess alles handeln kann, aber wieso die Embedded so funktioniert wie sie funktioniert, wirft schon Fragen auf :-)

[Lemmy]

guten Morgen,

Zitat:

Zitat von blackfin (Beitrag 1172582)

Gute Frage!! Mal ausprobieren...geht über studieren. Allerdings hatte ich beim FB embedded bei abstürzenden Programmen bisher noch nie Probleme mit Locks.

logisch - kanns auch nicht geben, weil Firebird ohne Locks funktioniert und ein komplett anderes Modell verwendet (Multigenerationenarchitektur)

Zitat:

Zitat von blackfin (Beitrag 1172582)

Würde mich selbst sehr interessieren, wie die neue Embedded-Superclassic-Architektur des 2.5 intern genau funktioniert.
Beim Client-/Server-Modell ist es ja klar, da ein Prozess alles handeln kann, aber wieso die Embedded so funktioniert wie sie funktioniert, wirft schon Fragen auf :-)

Helen Borrie bereitet gerade die Fortsetzung ihres Buches vor, das sich auch um FB 2.5 kümmern wird. Und ich vermute ganz stark, dass hier auch das Thema ausführlich behandelt wird. Eine "Beta" Version kann bei IBPhoenix.com auf der EntwicklerCD erworben werden. Damit kann man auch die Weiterentwicklung von Firebird finanziell unterstützen.

GRüße

[tsteinmaurer]

Wie es ganz genau funktioniert, das wissen nur die Core-Devs, aber vielleicht reicht dir das: Obwohl Firebird dem MVCC-Modell folgt, verwendet Firebird intern Locks und der "Lock Manager" ist die koordinative Komponente, um gemeinsam benutzte Ressourcen wie Data Pages etc. vor dem gegenseitigen Zugriff zu schützen. So speichert Firebird 2.5 unter Windows z.B. in einem Verzeichnis C:\ProgramData\Firebird sogenannte Lock-Files (Lock-Table), die der Lock-Manager verwaltet. Dadurch ist es auch möglich, dass ein Mischen von Classic/SuperClassic (inkl. Embedded, da auf SuperClassic basierend) für den Zugriff auf eine Datenbank auch schreibend funktioniert. Was man halt nicht machen kann, und was durch eine Fehlermeldung beim Connect von Firebird unterbunden wird ist, ein Mischen von 32 und 64-bit Firebird Prozessen, da sich hier das Layout der Lock-Table unterscheidet.

[himitsu]

Zitat:

Zitat von tsteinmaurer (Beitrag 1172608)

So speichert Firebird 2.5 unter Windows z.B. in einem Verzeichnis C:\ProgramData\Firebird sogenannte Lock-Files (Lock-Table),

Toll, daß heißt wenn ich den FBEmbedded in einem portablen Programm verwende, dann mülle ich alle möglichen Systeme zu?
Ich wollte die Embedded doch grade verwenden, damit das nicht passiert. :wall:

[Daniel]

Naja, zum Einen räumt FB die Dateien ja bei einem regulären Programm-Ende auch wieder auf und im Endeffekt musst Du Dich halt entscheiden, was Du alles an Funktionalität haben willst. Ich will nicht sagen, dass Du (gefühlt) ständig am Nörgeln bist, aber Du legst eine sehr hohe Messlatte an und ich hoffe, dass Du auch in Deinem eigenen Alltagsgeschäft mit den üblichen Randbedingungen (Zeit etc.) diesem Anspruch ebenfalls gerecht wirst.

[tsteinmaurer]

Es wird auch wieder aufgeräumt. :-D

Ach ja, hatte ich vergessen zu erwähnen: http://dyemanov.blogspot.fr/2012/05/...and-files.html

[himitsu]

Aber auch nur bei "normalem" Programmende ... wer sagt, daß sich mein Programm immer normal beendet? :roll:

Na gut, dann hoff ich mal, das räumt auch das Verzeichnis weg. :stupid:
War ja eher davon ausgegangen, daß es eben nur eine Anwendung pro Datenbankdatei ist ... wer hätte da geglaubt, daß nun doch wieder irgendwas Globales nötig ist.
Aber vielleicht kann man dieses Feature auch einfach deaktivieren?

Schade daß es kein globales Temp-Verzeichnis gibt, denn diese werden regelmäßig automatisch bereinigt. (bei mir privat, was leider nicht überall standardmäßig aktiv ist, und auch auf vielen Servern)
In das C:\Windows\Temp kann nicht jeder reinschreiben und ansonsten hat jeder Benutzer ein Eigenes, wo auch nicht jeder rann kommt. :?