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:

Zitat von hoika (Beitrag 1259580)

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:

Zitat von hoika (Beitrag 1259693)

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

[Perlsau]

Das Verhalten einer Delphi-Anwendung, die auf eine servergesteuerte Firebird-Datenbank zugreift, ist absolut identisch mit dem Verhalten bei Zugriff auf dieselbe DB im Embedded-Modus. Ich entwickle seit Jahren Firebird-DB-Anwendungen und hatte in dieser Zeit keinen einzigen Datenbank-Fehler durch Programmabstürze. Falls das doch einmal geschehen sollte, bin ich dennoch immer auf der sicheren Seite, da meine Client-Anwendungen größtenteils dazu fähig sind, DB-Backups zu erstellen: beim Start, beim Programmende oder sonstwo dazwischen. Alle meine Anwendungen werden bereits beim Projektbeginn so konzipiert, daß sie wahlweise als Server- oder Embedded-Variante einsetzbar sind. Dazu verwende ich die Parameterliste:

1. Variante: Wird eine kompilierte Firebird-DB-Anwendung ohne jeglichen Parameter gestartet, sucht sie beim Programmstart erst nach der Embedded-DLL (die ich stets fbclientE.dll nenne) und dann nach der benötigten Datenbank im Programmordner, der in diesem Fall ein beschreibbarer Ordner sein sollte.

2. Variante: Steht in der Parameterliste "0 F:\Datenbanken" (Aufruf der Exe: MeinProgramm.exe 0 F:\Datenbanken), wird ebenfalls die Embedded-DLL im Programmordner verwendet und er sucht im angegebenen Pfad nach der Datenbank.

3. Variante: steht in der Parameterliste "1 F:\Datenbanken", geht das Programm von einem installierten Firebird-Server aus, sucht im Windows-Verzeichnis nach der "normalen" Firebird-Library fbclient.dll. Wird diese nicht gefunden, sucht das Programm aus der Registry den Installationsordner des Firebird-Servers und nimmt die dortige DLL. Wird das auch nicht gefunden ... usw. Danach, wenn eine Firebird-Server-Installation und die DLL gefunden wurden, sucht das Programm im angegebenen Ordner nach der Datenbank. Wird diese nicht gefunden, sucht er im Programmordner danach. Wird sie dort auch nicht gefunden, bricht das Programm mit einer Fehlermeldung ab.

Eine 4. Variante wäre dann z.B. der Zugriff auf einen Remote-Server.

Anmerkung: Auch Anwendungen, die später ausschließlich im Embedded-Modus laufen sollen, entwickle ich gerne im Server-Modus. Der Grund war anfangs, daß die Embedded-Variante früherer Versionen keinen Multiuser-Zugriff gestattete und ich ständig vor dem Starten in der IDE die Datenbankverbindung im DB-Manager (bei mir: IbExpert) trennen mußte, weil sonst die DB-Verbindung meiner Anwendung nicht zustande kam. Heute mach ich das noch immer so, damit im Falle eines Falles auch immer alle Varianten zur Verfügung stehen.

[hoika]

Hallo Perlsau,

das klingt doch schon mal ganz gut!
Backups machen wir natürlich auch (gugg an, beim Start und Ende wie wir ;) ).

Bei uns benutzen wir die embedded DB beim Kunden eigentlich nur, wenn es unbedingt notwendig ist.

Bsp:
Ein fremdes Programm benutzt eine andere DB-Version oder rückt das sysdba-Passwort nicht raus,
um unseren eigenen User anzulegen.
Normalerweise umgehen wir das dann über "fbserver -a -p 3051".
Manchmal klappt aber ach das nicht.


Heiko

[Dejan Vu]

Ohne FB genau zu kennen: Ein RDMBS, das beim Schreiben die DB zerballern könnte, ist ein ziemlich schlecht geschriebenes. MySQL hat wohl mit der freien Storage-Engine so einen Bock abgeschossen, aber sonst sollte sich das ziemlich gut kontrollieren lassen. Denn schließlich stürtzt das OS ja nicht ab, das die Schreibvorgänge kontrolliert.

Das ist natürlich nur Theorie. Der IBExpert sollte das aber genau wissen.

[mkinzler]

Dieses Problem verschwindet hoffentlich, wenn FB3 mal fertig ist.

[Perlsau]

Naja, ich hab eigentlich immer nur Kleinkunden, die eine kleine spezielle Verwaltung benötigen, und das sind gewöhnlich keine PC-affinen Leute, die wollen nicht unbedingt was umständlich installieren, sondern am liebsten alles so einfach wie nur möglich. Deshalb sind meine Anwendungen meist Embedded-Varianten, die bei Bedarf natürlich auch mit einem installierten FB-Server laufen würden. Einige wollen abends den gesamten Programmordner auf ihrem Stick mit nach Hause nehmen oder in einer anderen Filiale einsetzen. Anwendungen, die von verschiedenen Betriebsstätten aus auf einen zentralen Server im Internet zugreifen, hab ich bislang nur einmal benötigt.

Backups bei Embedded-Betrieb mach ich meist nur als gewöhnliche Kopie der FDB-Datei, denn da kann nix schiefgehen, wenn die Verbindung zur Datenbank getrennt ist. Bei Server-Versionen laufen Backup und Restore natürlich über Gbak.

Zwar empfehle ich immer, beide Backup-Möglichkeiten (bei Start und Ende) zu nutzen, überlasse es aber letztlich meinen Anwendern, das über die Optionen selber einzustellen. Wichtig ist auch, beim Start-Backup einen anderen Dateinamen zu verwenden als beim Ende-Backup. Die luxuriöse Variante ist ein mit Datum versehenes Backup, was bei den relativ kleinen FDB-Dateigrößen, mit denen ich's gewöhnlich zu tun habe, kein Problem darstellt. Mehr wird (zumindest bei meiner Kundschaft) nicht wirklich benötigt.

Zitat:

Zitat von hoika (Beitrag 1259706)

Ein fremdes Programm benutzt eine andere DB-Version oder rückt das sysdba-Passwort nicht raus, um unseren eigenen User anzulegen. Normalerweise umgehen wir das dann über "fbserver -a -p 3051". Manchmal klappt aber ach das nicht.

Im Rahmen meiner Tätigkeiten für andere Entwickler gab es eigentlich nie Probleme damit, vom Hersteller der Fremdsoftware die entsprechenden Daten zu erhalten, nachdem wir uns dort als Entwickler einer Zusatz-Software vorgestellt und in einigen Fällen entsprechende Geheimhaltungspapiere unterzeichnet hatten. Wäre natürlich schwieriger, wenn es sich um Konkurrenzprodukte handeln würde, war aber nie der Fall. Die meisten Firmen setzen Standardsoftware ein, die von irgendwelchen spezialisierten Software-Häusern entwickelt wird. Letztere sind nicht unbedingt in der Lage oder willens, die vom Kunden gewünschte Zusatz-Software (z.B. eine automatische Katalogerstellung aus den Artikeldaten) zu entwickeln oder verlangen horrende Summen, weil der jeweilige Kunde angeblich der einzige sei, der so eine Zusatzfunktion benötige.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1259707)

Ohne FB genau zu kennen: Ein RDMBS, das beim Schreiben die DB zerballern könnte, ist ein ziemlich schlecht geschriebenes.

Man kann eine FB-Datei durchaus schrotten, wenn man z.B. mit IbExpert wie wild darin herumhantiert. Das beruht auf eigener leidvoller Erfahrung :twisted:
Wichtig ist daher immer, zuvor ein Backup anzulegen, dann kann ohne Angst vor Datenverlust nach Herzenslust herumexperimentieren. Die nachhaltigsten Erfahrungen macht der Mensch vermutlich noch immer durch Fehler, die richtig weh tun :P

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1259708)

Dieses Problem verschwindet hoffentlich, wenn FB3 mal fertig ist.

Ah. Also doch... (FB2).

Zitat:

Zitat von Perlsau (Beitrag 1259710)

Wichtig ist daher immer, zuvor ein Backup anzulegen...

Vor jeder Transaktion? :stupid:

:wall:

Ich geh jetzt andere Leute nerven (aka zur Arbeit)

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1259713)

Vor jeder Transaktion? :stupid:

Aus dem Kontext gerissen erhalten Aussagen häufig eine völlig andere Bedeutung als die ursprünglich intendierte :wall:
Aber für dich mach ich das nochmal gaaanz deutlich: Vor dem wilden Herumexperimentieren an einer Datenbank via IbExpert (resp. mit jedem anderen DB-Manager an jeder anderen beliebigen DB) :stupid:

Zitat:

Zitat von Dejan Vu (Beitrag 1259713)

Ich geh jetzt andere Leute nerven (aka zur Arbeit)

Die armen Kollegen :twisted:

[mkinzler]

Zitat:

Zitat von mkinzler:
Dieses Problem verschwindet hoffentlich, wenn FB3 mal fertig ist.
Ah. Also doch... (FB2).

Auch hier hast Du duch Auflösen des Kontextes einer Antwort, diese in eine komplett andere Aussage verwandelt!

Die Antwort bezog sich auf das Problem mit den Passwörtern. Den ab FB3 ist es möglich, die Benutzerverwaltung flexibler zu gerstalten (globale Rechtedatenbank [Verhalten FB <3], in der Benutzerdatenbank, in eigener (Rechte-)Datenbank [kann dann für mehrere Datenbanken verwendet werden]).

[Lemmy]

Zitat:

Zitat von hoika (Beitrag 1259706)

Bsp:
Ein fremdes Programm benutzt eine andere DB-Version oder rückt das sysdba-Passwort nicht raus,
um unseren eigenen User anzulegen.
Normalerweise umgehen wir das dann über "fbserver -a -p 3051".
Manchmal klappt aber ach das nicht.

dann installier doch deinen eigenen FB-Server mit eigenem Dienstnamen und eigenem Port. Vorteil: Du kannst jederzeit "deinen" Server aktualisieren, d.h. deinstallieren, neue Version drauf, ohne Angst haben zu müssen, dass sich jemand an deinen Server hängt und nach dem Update die andere Software nicht mehr funktioniert - weil Schuld bist sowieso du....

Grüße

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1259714)

Die armen Kollegen :twisted:

Ich habe wenigstens welche ;-)

[p80286]

[OT]

Zitat:

Zitat von hoika (Beitrag 1259706)

Ein fremdes Programm benutzt eine andere DB-Version oder rückt das sysdba-Passwort nicht raus,
um unseren eigenen User anzulegen.
Normalerweise umgehen wir das dann über "fbserver -a -p 3051".
Manchmal klappt aber ach das nicht.

(----------- Gedankenverbalisierung durch Zensur gestrichen ---------------------------)
Falls es sich um eine Datensammlung nur für ein Programm (anstatt TXT-Dateien) handelt, mag das ja noch angehen. Handelt es sich um Unternehmensdaten und ich habe keine Möglichkeit mit meinen Daten zu machen, was ich will, und vor allem auf meine Weise, dann fliegt der Anbieter schneller hinaus als er hereingekommen ist.

Gruß
K-H
[/OT]

[hoika]

Hallo Lemmy,

genau das hatte ich getan ...
FB2.01. als Application Port 3051 (-a -p 3051)

Erster Start -> es läuft.
Zweiter Start -> Nutzername oder Passwort falsch
Ds Programm will wieder FB2.5 benutzen.

Egal:
Ich habe ihm jetzt die embedded DB draufgepackt, es läuft.


Heiko

[Lemmy]

sorry, das habe ich überlesen... hat bei mir aber immer geklappt - entscheidend ist halt die ClientDLL und der ConnectionString

[Perlsau]

Genau! Und wenn man die entsprechenden Einstellungen als Parameter mitgibt (wie oben bereits beschrieben) – muß man nicht mal neu kompilieren, um den jeweils anderen DB-Server zu verwenden: Verknüpfung anlegen, Parameterliste hinter den Exenamen und fertig.