Unvailble Datatbase

[joachimd]

Der "Local System Account" (darunter laufen idR die Dienste) kennt keine Shares. Diese sind nur beim angemeldeten Benutzer bekannt. Verwende stattdessen einen UNC-Pfad für die Verbindung und nimm in die Freigabe auch den Local System Account mit auf. So ist es zumindest bei anderen DBMS mit ähnlicher Zugriffsstruktur.

[hoika]

Hallo,
Du bist ja auf FB5 umgestiegen.
Da gibt es NETBUI nicht mehr, deshalb klappt \\ nicht mehr.

Und FB will keine Netzlaufwerke haben.

[Delphi.Narium]

Die Benutzer benötigen keinerlei Zugriff auf die Verzeichnisse bzw. die Datenbankdateien. Den Zugriff benötigt nur der Datenbankserver. Den "Rest" kannst Du über die Konigurationsdateien des Firebirddatenbankservers konfigurieren.

Genaugenommen kann / sollte / muss es dem Entwickler egal sein, wo die Datenbankdatei liegt. Es reicht aus, wenn er den Aliasnamen vorgibt, unter dem seine Software auf "seine" Datenbank zugreift.

Wenn Nonames Datenbank LOGE-AKTUELL heißen soll, dann wird nur in der Konfiguration eine Alias LOGE-AKTUELL benötigt, bei dem Du dann für den Firebirdserver angibts, wo er die entsprechende Datenbankdatei findet. Die darf dann überall liegen wo der Firebirdserver bzw. der Benutzer, unter dessem Account er läuft, Zugriff hat.

Noname muss dann in der Ini-Datei lediglich "GDB=lvhost:LOGE-AKTUELL" angeben.

Und wenn morgen das Laufwerk, auf dem zur Zeit die Datenbankdateien liegen, zu klein wird, kannst Du einen Teil oder alle Datenbankdateien morgen auf ein anderes Laufwerk verschieben. Du muss dann nur den Alias in "Deiner" Firebirdkonfiguration ändern. Für den Client ist das transparent, sprich: Der merkt nix davon. Seine Konfiguration muss nicht angepasst werden, seine Benutzer oder Benutzergruppen müssen keine neuen oder geänderte Zugriffsrechte erhalten, derweil: Die brauchen die schlicht und einfach nicht. Sollten sie die Rechte doch benötigen, dann gewiss nicht für die Datenbankdatei. (Dann sollte man allerdings das genutzte Konzept hinterfragen.)

Bei 'ner Oracle-, SQL-Server-, PostGres-, MySQQL-Datenbank benötigen die Benutzer auch keine Zugriffsrechte auf die Datenbankdateien. Sie müssen nur wissen, wie sie den Datenbankserver erreichen, aber nicht, wo er die Daten letztlich physikalisch ablegt.

Das ist bei FireBird nicht anders, auch wenn es mit mehr oder weniger viel Aufwand bei Firebird im Rahmen des Möglichen ist.

Sehen wir es analog zur Delphipraxis: Wenn ich darauf zugreifen will, gebe ich im Browser halt https//:www.delphipraxis.net ein. Aber wo der dahinterliegende Datenbankserver seine Datenbankdateien hat, um welches Datenbanksystem es sich überhaupt handelt, muss ich nicht wissen, es geht mich nichtmal was an. Und irgendwelche Rechte auf dem Server benötige ich schonmal garnicht.

Das sollte bei eurer Software (meiner Meinung nach) nicht anders sein. In der Ini-Datei sollte nur der Name des Servers stehen, gefolgt von dem Namen (Alias) unter dem die Datenbank zu erreichen ist.

Prinzipell passt das von Dir beschriebene System

Zitat:

Ich kenne Firebird nicht, aber bei anderen SQL-Installationen werden die Datenbanken in den SQL-Server eingehängt und dann findet der Zugriff über <Servername oder IP><eventuell Port> und <Datenbankname> aus der Anwendung heraus statt.

auch bei Firebird.

In die Ini-Datei gehören auch unter FireBird <Servername oder IP><eventuell Port> und <Datenbankname>.

Wie Du dann als Admin letztlich den Datenbankserver einrichtest, sollte alleine Deine Aufgabe sein, da solten auch die Entwickler keine Vorgaben bezüglich der Verzeichnisstrucktur und / oder der Dateinamen für die Datenbanken machen. Das Einzige, auf das Ihr euch einigen müsst / solltet / könnt, ist der Name des Servers und des Alias, über die dann die Kommunikation zwischen Software und Datenbank stattfinden soll. Aber da das Informationen sind, die aus einer INI-Datei gelesen werden, solltest Du selbst das vorgeben dürften.

[IBExpert]

Zitat:

Das mit den Datenbanken in den Verzeichnissen ist vom Entwickler so vorgegeben.

gut, dann aber die frage, warum der umstand das da irgendwo im netztwerk ein datenbankserver sein muss.
Warum nicht mit dem embedded? der läuft als dll mit in deiner laufenden exe und kann eine datenbank
datei überall öffnen wo die via lokaler rechte auch erreichbar wäre. Wenn dann auf der db mehr als ein prozess
läuft, d.h. mehr als ein user braucht den gleichzeitigen zugriff auf die db ohne das ein server irgendwo installiert
ist, dann geht das ab firebird 3 auch problemlos, man muss dann für den embedded client in der lokalen firebird.conf
halt ganz unten classic einstellen.

das hätte bei dem betrieb auf einem share aber weiterhin alle schon bekannten nachteile in der performance.

und ohne das du mit der alten datenbankversion von jeder datenbank ein backup zB mit gbak machst in der alten
version und dann das restore mit dem fb5 gbak o.ä. wirst du dann eh nicht weiter kommen. bei der Konstellation
die euer Entwickler da hinterlassen hat, kann es auch noch gut sein, das du noch andere lustige nebeneffekte
feststellen wirst, wenn der Client nicht angepasst ist (also die delphi exe zB bestimmte tfield objekte referenziert
die in fb5 anders kommen wie count ist int64 usw. )

das kann man alles lösen, aber irgendwie hat euer entwickler da schon ein sehr seltsames konstrukt als basis hinterlassen.
bessere performance bei fb5 für single user datenbanken auf shares kannst du aber vergessen, falls das die motivation
zum umstieg ist.

wenn das um lauffähig machen geht bleib einfach bei fb25 auch auf dem neuen server, dann solltest du eigentlich nichts
an der alten config ändern müssen.

[harfes]

Noch eine vielleicht doofe Frage: wird "lvhost" im DNS überhaupt aufgelöst? Ich arbeite bei den Datenbanpfaden im Netzwerk immer mit der IP-Adresse (der Datenbankserver sollte ja eine feste IP haben...).

Hartmut

[Peasadas]

Zitat von harfes:

Noch eine vielleicht doofe Frage: wird "lvhost" im DNS überhaupt aufgelöst? Ich arbeite bei den Datenbanpfaden im Netzwerk immer mit der IP-Adresse (der Datenbankserver sollte ja eine feste IP haben...).

Hartmut

Ja, lvhost wird über DNS im Netzwerk aufgelöst.
Gruß
Fred

[Peasadas]

Herzlichen Dank für die Antworten,

der Server läuft tatsächlich im embedded Mode und die Anwendungen greifen über DLL auf die Datenbanken zu.
Ich habe die File-Struktur abgeändert, die Datenbanken sind jetzt über reale Laufwerke erreichbar und funktionieren.
Persönlich würde ich es lieber sehen, wenn die Datenbanken im Firebird registriert wären und der Zugriff
über IP-Adresse auf den Firebird läuft.
Das Leben ist kein Ponyhof, darum muss ich damit leben.

Noch mal herzlichen Dank für die konstruktiven Vorschläge.

Mit herzlichen Grüßen
Fred

[QuickAndDirty]

Zitat von Peasadas:

Kann Firebird nur auf reguläre Laufwerke, wie C., D, u.s.w. zugreifen?

JA nur auf reguläre Laufwerke ungemappt, das war zumindest für FB 2.5 der Fall und ich denke nicht das es sich geändert hat.

Zitat von Peasadas:

Oder kann Firebird auch auf Shares und UNC Pfade zugreifen.

Nein Netzwerkpfade gehen nicht, das war zumindest für FB 2.5 der Fall und ich denke nicht das es sich geändert hat.

Noch wichtiger für Admins: Firebird ist nicht VSS fähig! Man kann die FDB nicht im laufenden betrieb sichern und erwarten dass die Sicherung funktioniert oder dass der Server fehlerfrei weiterläuft ohne das sich z.b. Transactions aufhängen und nicht mehr beendne...
Also Firebird von live sicherungen über den Schattenkopien-dienst ausschließen und über gback sichern.

[Frickler]

Zitat von QuickAndDirty:

Nein Netzwerkpfade gehen nicht, das war zumindest für FB 2.5 der Fall und ich denke nicht das es sich geändert hat.

In der Firebird.conf gibt es einen Parameter, um das Verhalten zu ändern: RemoteFileOpenAbility.
Da steht aber auch "DO NOT ENABLE THIS OPTION UNLESS YOU REALLY KNOW WHAT YOU ARE DOING."

Siehe dazu auch: http://www.firebirdfaq.org/faq46/

Aber sie benutzen doch gar keinen Server. Peasadas schreibt "der Server läuft tatsächlich im embedded Mode". Das heißt, der "Datenbankserver" läuft tatsächlich auf dem Client!

Ich nehme mal an, das Prozedere mit den Freigaben für jeden User stammt noch aus der Urzeit, wo man möglicherweise mit Paradox oder dBase direkt auf die Daten zugegriffen hat. Und weil sich das so bewährt hat, wurde es für Firebird beibehalten. Einen "echten" Server nutzt man nicht, denn klar kann man über Alias auf die Datenbanken zugreifen, und klar kann man sich dann die Freigaben komplett sparen (ein Sicherheitsrisiko weniger!), und klar reicht es für den Client völlig aus, die IP des Servers zu kennen samt dem Alias, aber wie verhindert man, dass User A unberechtigt auf den Datenbank-Alias von User B zugreift? Das scheint das Hauptproblem zu sein; der Trojaner ist m.E. nur vorgeschoben.