Vor- und Nachteile von FB embedded für Einzelrechneranwendung

[hoika]

Hallo #,

wie schon im Titel geschrieben.
Gegeben: FB-Anwendung, läuft auf einem Rechner, also kein Netz

Vorteil 1:
keine FB-Installation, Anwendung könnte also sogar ohne Admin auf einem Stick "installiert" sein und laufen

Vorteil 1:
keine Probleme mit anderen ev. bereits installierten FB-s
Nutzername/Passwort muss nicht von dem anderen System "erfragt"/"erbettelt" werden

Nachteil 1:
Ein Fehler in der Anwendung reisst auch die FB-DLL mit -> Datenverlust ?
Was passiert, wenn die Anwendung "abgeschossen" ?

Kennt sich jemand gerade mit Nachteil 1 aus ?

Noch eine zweite Frage:
Woran erkennt ich eigentlich, dass die Anwendung mit einem embedded FB zusammenarbeitet?
Mit fällt hier nur ein, den Pfad der geladenen gds32.dll/fbclient.dll zu ermitteln
und die Größe der Dll zu prüfen (>1.5 MB).


Danke


Heiko

[mkinzler]

Zitat:

Nachteil 1:
Ein Fehler in der Anwendung reisst auch die FB-DLL mit -> Datenverlust ?
Was passiert, wenn die Anwendung "abgeschossen" ?

Wenn der Prozess nicht gerade bei einem Schreibvorgang aussteigt, sollte das kein Problem darstellen.

Zitat:

Noch eine zweite Frage:
Woran erkennt ich eigentlich, dass die Anwendung mit einem embedded FB zusammenarbeitet?
Mit fällt hier nur ein, den Pfad der geladenen gds32.dll/fbclient.dll zu ermitteln
und die Größe der Dll zu prüfen (>1.5 MB).

Das ist kein Indiz, da die embedded(Server)-Dll ja uach über Netzwerkprotokoll auf einen installierten lokalen/remoten Server zugreifen kann. Grundsätzlich sollte jedes Programm, welches auf FB zugreift problmelos embedded funktionieren.

[jobo]

Zitat von hoika:

Nachteil 1:
Ein Fehler in der Anwendung reisst auch die FB-DLL mit -> Datenverlust ?
Was passiert, wenn die Anwendung "abgeschossen" ?

Kennt sich jemand gerade mit Nachteil 1 aus ?

Ich denke, das ist kein spezifischer embedded Nachteil.
Ob es der Server nicht schafft Daten wegzuschreiben oder die embedded DLL macht keinen Unterschied oder?
Alle Datenschreiber müssen per se auf hohe Robustheit ausgelegt sein. Dazu werden die verschiedensten Mechanismen verwendet.
Was auch immer geschieht, fehlt ein finales commit, sind die Daten futsch.

[mkinzler]

Nur einen Server kann ein Benutzer nicht so einfach abschiessen und beim geordneten Beenden des Dienstes wird ja alles sauber beendet.
Ich vermute mal er meint beim "harten" Beenden des Programmes z.B. über den Taskmanager. Dann wird die Dll (und damit der "Server" im Bauch dieser) beendet und es kann nicht richtig aufgeräumt werden.

[jobo]

Ja, die Wahrscheinlichkeit für einen solchen Fall ist sicher höher mit embedded auf einer Workstation.
Aber es geschieht m.E. nichts anderes, als bei einem Server.
Selbst wenn nicht der Server sondern nur das Clientprogramm abschmiert/gekillt wird.
Wenn kein commit mehr kommt, speichert auch der Server die Daten nicht.

[p80286]

Meiner Meinung nach ist das ein Problem des Programmieres.
Wenn er nach jedem Datenhäppchen ein commit abschickt, ist es sicherer als wenn erst einmal gesammelt wird und dann irgendwann das MB DB-Futter losgeschickt wird.

Dieses Risiko besteht allerdings sowohl bei embedded als auch bei Server-DBs.

Gruß
K-H

[hoika]

Hallo,

danke für Ihre Meinungen.

Ich meine in der Tat das (auch ungewollte) Beenden der eigenen Anwendung.
Stürzt die Anwendung ab und der (nicht embedded) Server schreibt noch was, OK,
habe ich eine embedded DB, kann es doch sein, dass die DB beschädigt wird ?.

Es geht also nicht um Datenverlust wegen fehlendem Commit,
sondern um beschädigte DB's.


Heiko

[BUG]

Zitat von hoika:

habe ich eine embedded DB, kann es doch sein, dass die DB beschädigt wird ?.

Das sollte bei einem ordentlichen Datenbanksystem nicht passieren.
Wenn dein Anwendung sehr häufig abstürzt, steigt natürlich die Wahrscheinlichkeit, das du auf einen Bug stößt; ansonsten sollte eine Datenbank einen Crash ohne Korruption.

[hoika]

Hallo Bug,

du weisst schon, dass wir hier von einer Dll im Prozessraum der eigenen Anwendung reden ?



Heiko

[p80286]

Was verstehst Du eigentlich unter "beschädigt"?

Gruß
K-H