<< Datenbankregistrierung löschen | IBExpert | Erneut verbinden >>

Die deutschsprachige Dokumentation wird seit dem 26. Juli 2016 nicht mehr gepflegt. Aktuelle und vollständige Dokumentation finden Sie auf der englischsprachigen Webseite: IBExpert Documentation

Verbinde mit Datenbank

Nachdem Sie IBExpert gestartet haben, sehen Sie auf der linken Seite den Datenbank Explorer. Bevor eine Datenbankverbindung hergestellt werden kann, muss die Datenbank registriert werden (weiteres unter Datenbank registrieren).

Eine Datenbankverbindung mit einer registrierten Datenbank kann einfach per Doppelklick auf den Datenbank-Aliasnamen, der im DB Explorer angezeigt wird, hergestellt werden. Außerdem gibt es eine Vielzahl an Menüoptionen: entweder Sie verwenden den IBExpert Menüpunkt Datenbank / Verbinde mit Datenbank oder folgendes Symbol (Icon):

in der Datenbank Symbolleiste. Alternativ kann das DB Explorer Rechtsklickmenü verwendet werden oder die Tastenkombination [Umschalt + Strg + C].

Es ist möglich automatisch beim Start von IBExpert mit einer Datenbank zu verbinden. Verwenden Sie das folgende Menü: Datenbankregistrierungsinfo / Zusatzeinstellungen und aktivieren Sie: Datenbank öffnen, wenn IBExpert gestartet wird.

Sollten Probleme beim Verbinden mit der Datenbank auftreten, nutzen Sie das IBExpert Menü Systemdienste / Kommunikationsdiagnose.

Ein Beispiel zur Verbindung mit einer Remote-Datenbank mit Hilfe des IBExpert Datenbankmenüpunkts Datenbankregistrierungsinfo:

Natürlich sollte Firebird/InterBase^® korrekt auf dem Server PC (wo sich Ihre Datenbank befindet) und der Firebird/InterBase^® Client (fbclient.dll oder gds32.dll) auf dem lokalen PC installiert sein.

Für diejenigen, die die Verwendung von SQL bevorzugen; die Syntax lautet, wie folgt:

 CONNECT [TO] {ALL | DEFAULT} <config_opts>
 | <db_specs> <config_opts> [, <db_specs> <config_opts>...];

 <db_specs> = dbhandle 
 | {'filespec' | :variable} AS dbhandle 

 <config_opts> = [USER {'username' | :variable}] 
 [PASSWORD {'password' | :variable}]
 [ROLE {'rolename' | :variable}] 
 [CACHE int [BUFFERS]]

Ein Teilsatz von CONNECT Optionen steht in isql zur Verfügung.

 CONNECT 'filespec' [USER 'username'][PASSWORD 'password']
 [CACHE int] [ROLE 'rolename']

Die CONNECT Anweisung:

• Initialisiert Datenbankdatenstrukturen.
• Legt fest, ob die Datenbank eine lokale Datenbank ist oder aus einer anderen Verknüpfung (einer Remote Datenbank)

Wenn Firebird/InterBase^® die Datenbank nicht lokalisieren kann, erscheint eine Fehlermeldung.

• Definiert optional einen oder mehrere Benutzernamen, Passwörter, Roles fest, die bei Zugriff auf die Datenbank verwendet werden. PC-Clients müssen immer einen gültigen Benutzernamen und Passwort eingeben. Firebird/InterBase^® erkennt nur die ersten 8 Zeichen eines Passworts.

• Verbindet mit der Datenbank und verifiziert die Kopfseite. Die Datenbankdatei muss eine gültige Datenbank enthalten und die (ODS) Versionsnummer der Datenbank muss die von der auf dem Server installierten Firebird/InterBase^® Version erkannte sein, sonst erzeugt Firebird/InterBase^® eine Fehlermeldung.
• Etabliert optional einen Datenbankalias, der in einer SET DATABASE Anweisung deklariert ist.
• Bestimmt einen Cachespeicher für den Datenbankverbindungsprozess.

In SQL Programmen muss die Datenbank mit der SET DATABASE Anweisung deklariert werden, bevor sie mit CONNECT geöffnet werden kann. isql verwendet nicht SET DATABASE. Verwenden Sie in SQL Programmen verschiedene Anweisungen, um den Code einfach lesbar zu halten, auch wenn Sie dieselbe CONNECT-Anweisung verwenden, um mehr als eine Datenbank zu öffnen.

Wenn CONNECT mit eine Datenbank verbindet, wird der Standardzeichensatz (NONE) verwendet, oder ein in einer vorangegangenen SET NAMES Anweisung definierter Zeichensatz.

In SQL Programmen ändert die CACHE-Option den Cachegrößenzähler (die Gesamtgröße des verfügbaren Cachespeicher) von der Standardeinstellung. Diese Option kann verwendet werden um:

• eine Standardeinstellung für alle Datenbanken vorzunehmen, die in der CONNECT-Anweisung gelistet sind, sofern diese nicht schon eine bestimmte Cachegröße haben.
• einen Cache für ein Programm fetszulegen, das eine einzelne Datenbank verwendet.
• den Cache für eine Datenbank zu ändern, ohne die Standardeinstellung für alle anderen, von diesem Programm verwendeten Datenbanken zu ändern.

Die Größe des Cache hat Bestand, solange die Verbindung aktiv ist. Wenn eine Datenbank bereits über einen Multi-Client-Server verbunden ist, erfolgt ein Anstieg der Cachegröße durch die neue Verbindung, solange, bis die Verbindungen enden. Eine Verringerung der Cachegröße hat keine Auswirkung auf Datenbanken, die bereits mit einem Server verbunden sind.

Ein Subset von CONNECT-Features ist in isql erhältlich: Datenbankdateiname, USER, und PASSWORD. isql kann nur mit einer Datenbank zur Zeit verbunden werden. Jedes Mal, wenn CONNECT verwendet wird, um mit einer Datenbank zu verbinden, werden vorherige Verbindungen gelöst.

Syntax freundlicherweise zur Verfügung gestellt von IBPhoenix (https://www.ibphoenix.com)

zurück zum Seitenanfang

Zugriff auf eine eingebettete Firebird Datenbank mit WIN1252 (oder anderem Zeichensatz)

Diese Tipps kommen von Gerhard Knapp.

Datenbankverbindung mit einer eingebetteten Firebird Datenbank mit WIN1252 (oder anderem Zeichensatz) mit Hilfe von IBExpert:

1. fbembed.dll umbenennen in fbclient.dll (immer empfohlen, nicht nur in diesem Fall!)
2. Definieren Sie fbclient.dll inklusive Laufwerk und Pfad in der IBExpert Datenbankregistrierung.
3. WIN1252 in IBExpert.
4. Unterverzeichnis intl vom Programmdateiverzeichnis kopieren, wo fbclient.dll installiert ist, in das Verzeichnis C:\Program Files\HK-Software\IBExpert 2.0!!

Dann sollten keine Probleme mehr auftauchen!

Weitere Informationen:

Wenn fbembed.dll umbenannt wurde in fbclient.dll, ist sie ebenfalls ein vollwertiger Client, d.h. wenn eine Anwendung auf eine eingebettete Datenbank auf einem Firebird Server zugreift, ist die fbclient.dll absolut ausreichend.

zurück zum Seitenanfang

Datenbank Login

Wenn bei der Registrierung der Datenbank (siehe Datenbank registrieren) kein Kennwort engegeben wird, wird bei jedem Öffnen der Datenbank das Kennwort erneut abgefragt.

Bestimmen Sie einen Benutzernamen und ein dazugehöriges Kennwort. Wenn der Benutzer nicht authorisiert ist, oder das Kennwort nicht korrekt ist, erscheint eine Fehlermeldung.

Optional kann eine Role bestimmt werden. Wenn eine Role vorher schon einem Benuntzernamen zugeordnet wurde, werden alle Rechte, die der Role zugewiesen wurden für die Dauer der aktuellen Session auch dem Benutzer zugewiesen.

Passwort anzeigen-Checkbox: wenn aktiviert, wird das tatsächliche Passwort statt eine Reihe Sternchen angezeigt.

Die Das Auslösen Datenbank-/Transaktionstrigger verhindern-Checkbox-Option ist die isc_dpb_no_db_triggers-Option in Zusätliche Verbindungsparameter gleich.

Wenn der Benutzer ein autorisierter Benutzer für den Server ist und wenn das Kennwort korrekt ist, wird der Zugriff auf die Datenbank gewährt.

zurück zum Seitenanfang

Remote-Datenbankverbindung mittels Alias

Dieser Artikel wurde von Claudio Valderrama verfasst( https://www.cvalde.net/ - The InterBase^® Unofficial Site), Februar 2002

Viele Entwickler möchten verhindern, das der Client der Maschine den vollständigen Pfad auf derselben Maschine (Verknüpfung) angeben muss, auf der die Maschine läuft. Es ist nicht nur lästig, wenn der Speicherort der Datenbank geändert wird, damit sollte der Client einfach nicht behelligt werden. Letztendlich haben viele Entwickler Bedenken wegen der Sicherheit. Idealerweise sollten der physische Speicherort der Maschine und der, der Datenbank nicht dem Client offenbart werden; es sollte lediglich ein Alias sichtbar sein.

Es ist unglaublich, dass jahrelang eine Lösung in der Maschine (die funktioniert, wenn der Server eine NT-Maschine ist) im Code eingebaut war und keiner hat es bekannt gemacht, oder wenigstens in einer Hilfedatei dokumentiert. Vielleicht, weil es leider nur eine Win32 Lösung ist, nicht unter Linux verwendbar, sodass der Speicherort einer gdb nicht wirklich transparent ist.

Die Syntax ist sehr einfach:

 \server!share_name!database.gdb@@

oder

 server:!share_name!database.gdb

Es ist kein wirklicher Alias, da Sie immer noch den Namen der Datenbank kennen und natürlich sollte die Servermaschine bekannt sein. Aber es hilft, wenn Sie die Datenbank auf dem NT Server verschieben müssen, ohne die Konfigurationsdatei ändern zu wollen oder das Programm erneut zu kompilieren. Hier ist "server" der NetBEUI-Name der NT Maschine, gefolgt von dem Pseudo-UNC-Pfaden, die IB/FB verwenden. Alternativ ist "server" der TCP/IP-Name der NT Maschine, allerdings gefolgt von Backslashes, nicht den typischen Slashes (Schrägstrichen) die von IB's Syntax verwendet wird. (Die Verwendung von Backslashes oder Slashes (Schrägstrichen) ist nicht wirklich wichtig in einem typischen vollständigen Pfad, da die Maschine die Anpassung vornimmt, aber in diesem Fall erfordert die Syntax zur Erkennung der Share-Befehle Backslashes.) Der Unterschied ist, dass anstatt eines vollständigen Pfades innerhalb des Servers der Name des Share-Befehls, eingerahmt von Ausrufezeichen, verwendet wird.

Diese Share-Punkte werden zu den vollständigen Pfaden der Datenbank, sodass Sie nur noch den Datenbanknamen anhängen müssen. Dies hat nichts mit Client-seitigem Mapping zu tun.

So funktioniert es: Die Client-Bibliothek erkennt den UNC-ähnlichen Pfad und weiß, dass es NetBEUI ist. Andererseits erkennt sie die TCP-ähnliche Syntax Dank des Doppelpunktes. Dann verbindet sie mit dem gewünschten Server mit dem richtigen Netzwerkprotokoll und gibt den Rest des Pfades weiter, womit der Servername preisgegeben wird. Eine Routine innerhalb der Maschine, genannt expand_share_name, wird, von Backslashes gefolgt, nach einem Ausrufezeichen suchen und wenn eine Übereinstimung gefunden wurde, setzt es den Namen in zwei Paar ("!" und "!") und öffnet die Registratur (RegOpenKeyEx) unter,

 SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

um die Daten (RegQueryValueEx) in dem Wert <share_name> zu extrahieren , der der Name eines registrierten Shares in der Server-Maschine sein soll. Die Daten werden weiter decodiert und die Client-Bibliothek erhält die "Path" Komponente innerhalb der Multistringdaten, die dem physischen Pfad entsprechen. Der Pfad wird geladen und bei Anfrage zurückgegeben, wonach getestet wird, ob der Datenbankname gültig und vorhanden ist.

Beispielsweise, wenn ein Share-Name "myshare" vergeben wurde, enthalten die oben gezeigten Registrierungsschlüssel eine Liste von Werten, die Shares kennzeichen. Sie finden dort die Implizierten, wie IAS1$ (sehr schlecht, sehen Sie zu, das Sie es los werden, weil es zur IIS admin dir führt), die NETLOGON Share und "myshare". Beim Lesen der Daten in dem Wert"myshare" sehen Sie folgendes:

 MaxUses=4294967295.Path=H:PROY.Permissions=127.Remark=for fb.Type=0..

Die Punkte kennzeichnen den NULL ASCII Wert, da dies ein Multistring ist. Die Maschine sucht nach "path" und erhält folgenden String: H:PROY, dann ergänzt sie den Backslash, falls dieser fehlt. Demzufolge verwendet die Maschine Informationen im Server selbst, um den vollständigen Pfad zu decodieren. Dieser Pfad wird bei Rückgabe der Funktion expand_share_name an den Aufrufer als Präfix dem Datenbanknamen vorangestellt.

Der Vorteil ist, dass Sie diesem Share keine Erlaubnis zuweisen müssen. Sie können jedem jedes Rechts verweigern (sogar wenn NT fragt, ob Sie sicher sind) und Sie können noch weiter gehen: Sie können den Dienst stoppen, der für die Bearbeitung der Anfragen von NetBEUI Shares zuständig ist. Die Maschine liest die Registrierung direkt, so dass die Netzwerkschichten nicht abgefragt werden. Es ist ein echter Hack, ein Produkt zur Vermeidung der Einbeziehung hart-codierter Pfade in den Client. Wenn Sie es ändern möchten, ändern Sie nur die Share Information, ohne irgendjemandem irgendwelche Rechte in dem Share zuzuweisen. Da die Maschine den Registrierungsort jedesmal liest, wenn ein Verbindungsstring analysiert werden soll, wird es die Änderung mit der nächsten Anfrage erhalten. Wenn Sie einige Netzwerkdienste deaktivieren, sodass die Änderung des Shares nicht durch Highlevel-Interfaces möglich ist, können Sie die Registrierung direkt bearbeiten und den Pfad ändern. Beachten Sie, dass jeder Punkt einen NULL ASCII Wert darstellt, wie im Beispiel oben gezeigt, also sollte Ihr Pfad mit dem Wert enden. Ein noch besseres Feature ist folgendes:

 H:ibdevfbbuildinterbasejrd>isql \atenea!myshare!g
 Database: \atenea!myshare!g
 SQL> ^Z

Dies beschränkt sich allerdings nicht auf NetBEUI. Tatsächlich können Sie, wie zuvor erwähnt, TCP-Syntax verwenden:

 H:ibdevfbbuildinterbasejrd>isql localhost:!myshare!g
 Database: localhost:!myshare!g
 SQL> ^Z

(Bedenken Sie, dass es keine Einschänkungen zu Namen einer gdb gibt, im Gegensatz zu den Bedingungen für Dateinamen auf der Plattform, wo sich auch die Maschine befindet. (In diesem Fall wird es einfach "g" genannt, obwohl eine Erweiterung dem Datenbankadmin hilft.)

Es gibt einige Nachteile: erstens, der Hack ist an Win32 gebunden. (Außerdem, kenne ich keine Möglichkeit es auf XP zu testen, aber ich hörte von einem erfolgreichen Test auf Windows 2000.) Zweitens, als ich die interen Funktionen expand_share_name() las, fand ich einen möglichen Überlauf-Puffer und schloss sie. Als ich den Code beim Schreiben dieses Artikels erneut öffnete, fand ich eine Bearbeitungsmöglichkeit für Registrierungsschlüssel, die nicht geschlossen wird, falls die Funktion vorzeitig wegen Speichermangel schließt. (Ich habe dieses zweite Problem in Firebird gelöst, als ich mit diesem Artikel fertig war.)

Somit glaube ich, dass die fehlende Dokumentation auf der Tasache beruht, dass diese Möglichkeit bis dahin nicht getestet wurde.

Siehe auch:
deutschsprachig:
Kommunikationsdiagnose
Datenbank Symbolleiste

Syntax freundlicherweise zur Verfügung gestellt von IBPhoenix (https://www.ibphoenix.com)

zurück zum Seitenanfang
<< Datenbankregistrierung löschen | IBExpert | Erneut verbinden >>