DB-Auswahl: FB embedded mit externem Zugriff?

[messie]

Moin,

ich habe eine Software, die lokal Daten produziert und ablegt (bisher als ASCII). Gegegentlich (also ein paarmal im Monat) greift die Qualitätssicherung übers Netz auf die Daten zu. Die Suche darin ist recht umständlich und die Datenmenge mittlerweile recht groß, so dass es lange dauert.
Für die lokale Anwendung würde sich FB embedded anbieten. Die Frage ist, wie der externe Zugriff gestaltet werden kann. Für einen Server ist mir die Sache eigentlich zu klein und es ist niemand zum Administrieren da. Alle paar Jahre wird so ein Prüfstand neu gebaut und ins chinesische Hinterland geliefert. Die brauchen dann keinen externen Zugriff. Dafür muss das alles mit einer Installationsroutine ohne besondere Eingaben klappen.
Bisher gibt es noch keine Präferenzen, für den Zugriff hatte ich dbx im Auge - die Komplexität der Aufgabe hält sich ja in Grenzen. Auch die Aktualität der Daten hat eine geringe Priorität.
Wenn man jetzt die Datenbank-Datei regelmäßig (die Intervalle müsste man noch klären) auf ein anderes Laufwerk spiegelt, müsste eine andere Installation die doch wie die lokale embedded-DB behandeln können. Ist das richtig?

Danke, Messie

[OT]Duck and Cover - Messie goes Datenbanken[/OT]

[mkinzler]

Ein Firebird-Server ist eigentlich recht administrationsarm.

[messie]

Zitat:

Zitat von mkinzler (Beitrag 1175004)

Ein Firebird-Server ist eigentlich recht administrationsarm.

Kann man den so vorkonfigurieren, dass er mit der einmaligen Eingabe eines Users und Passworts läuft, ohne dass da jemals wieder nach gesehen werden muss?

Wer möchte schon gerne ins chinesische Hinterland, vor allem auf eigene Kosten :pale:

Grüße, Messie

[user0815]

Warum nicht SQLite? Die QS könnte sich dann einfach die DB ziehen / zukommen lassen.

[mkinzler]

Zitat:

Zitat von user0815 (Beitrag 1175009)

Warum nicht SQLite? Die QS könnte sich dann einfach die DB ziehen / zukommen lassen.

Selbiges gilt für Firebird (embedded)

Zitat:

Kann man den so vorkonfigurieren, dass er mit der einmaligen Eingabe eines Users und Passworts läuft, ohne dass da jemals wieder nach gesehen werden muss?

Der Server wird standardmässig mit SYSDBA / masterkey installiert.

[tsteinmaurer]

Was heißt:

Zitat:

greift die Qualitätssicherung übers Netz auf die Daten zu

Per SQL oder kopieren der Daten auf Dateisystemebene?

Im Prinzip steht dir mit Firebird alles offen: Regulärer Firebird Server mit User/Passwort Anlage als Post-Task deines Installers, oder du nimmst den Default SYSDBA/masterkey (allerdings nicht zu empfehlen). Embedded hernehmen, wo kein Multi-User Zugriff übers Netz möglich ist, sondern z.B. Kopie der Datenbank, wenn niemand verbunden ist etc.

[messie]

Zitat:

Zitat von tsteinmaurer (Beitrag 1175021)

Was heißt:

Zitat:

greift die Qualitätssicherung übers Netz auf die Daten zu

Per SQL oder kopieren der Daten auf Dateisystemebene?

Bisher noch auf die ASCII-Daten, die auf einem Dateiserver liegen. Sowohl am Prüfstand als auch in der QS wird dasselbe Programm verwendet, nur dass in der QS die Datenaufnahme mangels Hardware deaktiviert ist.

Zitat:

Zitat von user0815 (Beitrag 1175009)

Warum nicht SQLite? Die QS könnte sich dann einfach die DB ziehen / zukommen lassen.

Wir haben noch ein weiteres Programm, in dem eine Interbase 6 verbaut ist. Die könnte evtl. mal ihrem Programmierer in den Ruhestand folgen und dann stelle ich mir den Umstieg auf Firebird deshalb leichter vor, weil damit sehr viel Erfahrung vorliegt. Und daher bin ich bei der Auswahl ganz leicht :wink: in die Richtung fokussiert.

Zitat:

Zitat von tsteinmaurer (Beitrag 1175021)

Im Prinzip steht dir mit Firebird alles offen: Regulärer Firebird Server mit User/Passwort Anlage als Post-Task deines Installers(...)

Da möchte ich noch mal nachfragen, wie ich mir das vorstellen kann. Etwa: Installation mit manueller Festlegung des DB-Pfads, nach Abschluss der Aufruf eines mitinstallierten Konfigurationsprogramms mit entsprechenden Parametern ohne GUI oder Aufruf mit GUI?
Wie sieht es dann mit den Zugriffsrechten aus? Darf die QS-Installation mit denselben Userdaten zugreifen? Dort würde ich dann eine manuelle Konfiguration vorsehen.
Eine einmalige Eingabe eines Passworts/Benutzernamens kann man ja als Anleitung mitgeben. Aber nur, wenn für alle Installationen derselbe Anmeldename zulässig wäre.

Hört sich alles schon mal gut an :thumb:

Danke, Messie

[mkinzler]

Zitat:

Die könnte evtl. mal ihrem Programmierer in den Ruhestand folgen und dann stelle ich mir den Umstieg auf Firebird deshalb leichter vor, weil damit sehr viel Erfahrung vorliegt. Und daher bin ich bei der Auswahl ganz leicht

Zudem hat FB den Vorteil, dass man leicht auf einen Server migrieren kann.

Zitat:

Da möchte ich noch mal nachfragen, wie ich mir das vorstellen kann. Etwa: Installation mit manueller Festlegung des DB-Pfads, nach Abschluss der Aufruf eines mitinstallierten Konfigurationsprogramms mit entsprechenden Parametern ohne GUI oder Aufruf mit GUI?

Das ist kein Problem.

Zitat:

Wie sieht es dann mit den Zugriffsrechten aus? Darf die QS-Installation mit denselben Userdaten zugreifen? Dort würde ich dann eine manuelle Konfiguration vorsehen.

Man kann auch verschiedene Benutzer (am Server) anlegen und denen in der Datenbank verschiedene Rechte/Sichten einrichten.

[messie]

Man kann auch verschiedene Benutzer (am Server) anlegen und denen in der Datenbank verschiedene Rechte/Sichten einrichten.[/QUOTE]
AUCH heißt, dass sich EIN user von zwei Standorten gleichzeitig anmelden kann?
Unterscheidliche Rechte und Sichten sind hier gar nicht nötig.

Grüße, Messie

[tsteinmaurer]

Zitat:

AUCH heißt, dass sich EIN user von zwei Standorten gleichzeitig anmelden kann?

Im Falle eines dezidierten Firebird Server Prozess, ja, natürlich. Das ist Sinn und Zweck eines multi-user fähigen DBMS, dass mehrere User gleichzeitig die Datenbank abfragen etc. können.

[messie]

Moin,

ich werde das Thema hier mal fortsetzen, da ich jetzt wieder dran bin. Ich habe etwas für mich Überraschendes heraus gefunden: Wenn ich die IB6 durch FB ersetze, läuft mein IB6-Programm bis auf eine Menge Typanpassungen von D6 nach XE2 als wäre gar nichts geändert worden.

Wenn ich eine Firebird-DB erstelle, kann ich jedoch nicht auf die DB zugreifen, da in der Software IB-Komponenten verwendet sind.
Jetzt die Frage: bringt es in diesem Fall etwas, die DB nach FB zu migrieren? Bisher geht da alles. Müsste ich dann andere Komponenten nehmen? Gibt es etwas gegen die weitere Verwendung der IB6-Datenbank einzuwenden?

Danke, Messie

[mkinzler]

Zitat:

Wenn ich die IB6 durch FB ersetze, läuft mein IB6-Programm bis auf eine Menge Typanpassungen von D6 nach XE2 als wäre gar nichts geändert worden.

Was hast du ausgetaucsht? Den Dienst?

Zitat:

Wenn ich eine Firebird-DB erstelle, kann ich jedoch nicht auf die DB zugreifen, da in der Software IB-Komponenten verwendet sind.

Wenn die Client-Dll in der gds32 Variante vorhanden ist, sollte damit auch ein Zugriff möglich sein.

Zitat:

Jetzt die Frage: bringt es in diesem Fall etwas, die DB nach FB zu migrieren? Bisher geht da alles. Müsste ich dann andere Komponenten nehmen? Gibt es etwas gegen die weitere Verwendung der IB6-Datenbank einzuwenden?

In FireBird wurden viele Fehler berreinigt und neue Features hinzugefügt. Zudem ist das DBMS schneller als IB6

[messie]

Zitat:

Zitat von mkinzler (Beitrag 1183431)

In FireBird wurden viele Fehler berreinigt und neue Features hinzugefügt. Zudem ist das DBMS schneller als IB6

Das ist natürlich ein Argument.
Getauscht habe ich den Dienst, die Entwicklungsumgebung und den Programmierer (:mrgreen:)

Für den Zugriff ein paar IB-Kompos auf ein Form getan und mit der FB-Datenbank verbunden. Im IBTable kann ich nicht auf die vorhandenen Tabellen zugreifen (Table unknown). Wenn ich als Database die IB6-Datenbank einstelle, geht das und ich kann mir die Tabelle z.B. in einem Grid anzeigen lassen.

Grüße, Messie

[mkinzler]

IBX funktioniert zwar noch für FireBird, unterstützt es aber nicht richtig. Zudem wird die Kompatibilität eher abnehmen.

[messie]

Zitat:

Zitat von mkinzler (Beitrag 1183435)

IBX funktioniert zwar noch für FireBird, unterstützt es aber nicht richtig. Zudem wird die Kompatibilität eher abnehmen.

Was für eine Migration der DB von IB nach FB bedeutet, dass die Komponenten nicht weiter verwendet werden können :?

[mkinzler]

Oder man beschränkt sich auf die Features von IB6, was aber imho nicht sinnvoll ist.

[Lemmy]

Zitat:

Zitat von messie (Beitrag 1183437)

Zitat:

Zitat von mkinzler (Beitrag 1183435)

IBX funktioniert zwar noch für FireBird, unterstützt es aber nicht richtig. Zudem wird die Kompatibilität eher abnehmen.

Was für eine Migration der DB von IB nach FB bedeutet, dass die Komponenten nicht weiter verwendet werden können :?

Was kein so großes Problem sein muss: Ich bin von IBX nach IBDAC gewechselt, die haben einen Wizard dabei, mit dem habe ich die Umstellung einer Software recht schnell erledigt (ca. 100 Tabellen, Anzahl FOrmulare weiß ich gerade nicht).

Generell würde ich IBX und Firbird > 1.5 nicht mehr einsetzen - ich hatte damit viele Probleme und bin übers Testen nie raus gekommen.

Grüße

[user0815]

warum IBDAC & nicht UniDAC, übersehe ich da etwas?

http://www.devart.com/unidac/
vs
http://www.devart.com/ibdac/

bei der Standard Edition ist der Preis sogar gleich...

[DeddyH]

Du hast da etwas übersehen:

Zitat:

The Standard edition includes the UniDAC common engine, but does not include any data providers. UniDAC Standard Edition supports only the following data providers: Oracle, SQL Server, MySQL, InterBase (Firebird), PostgreSQL, and SQLite which are installed by ODAC, SDAC, MyDAC, IBDAC, PgDAC, and LiteDAC correspondingly. UniDAC Standard Edition is a cost-effective solution for those database application developers who need only several of supported data providers and already have (or are going to have) some of DACs.