Fehler beim Öffnen einer Firebird Datenbank

[hanspeter]

Hallo,
ich habe mit Firebird ein Problem, wo ich im Moment keine Erklärung finde.
Ich starte auf dem Rechner ein Programm. Dieses verbindet sich zu einer Firebird-Datenbank.
Der Zugriff erfolgt über IBDAC.

Starte ich jetzt auf dem gleichen Rechner ein anderes Programm, welches auf die gleiche Datenbank zugreifen soll,
dann kommt nachfolgender Fehler:

Fehler beim Öffnen der Datenbank.
I/O Errorfile "C:\Programm _Files\Test\Database.fdb.
Error while trying to open file.
Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.

Dürfte bei einem Server eigentlich nicht passieren. (Adressiert über localhost)

Hat wer eine Idee, wo ich suchen muss?

Mit Gruß
Peter

[mkinzler]

Verwendet das andere Programm vielleicht den Embedded-Server-Client?

[hanspeter]

Zitat:

Zitat von mkinzler

Verwendet das andere Programm vielleicht den Embedded-Server-Client?

Nein, den habe ich garnicht installiert.
Es ist auch nur eine FBClient.dll da.
Das Programm greift auf zwei unterschiedliche Datenbanken zu.
Die eine Verbindung fuktioniert.
Die Datenbank, auf welche kein Multiuser Zugriff möglich ist, liegt unter Vista in c:\Programme\....

Gruß
Peter

[mkinzler]

Zitat:

Es ist auch nur eine FBClient.dll da.

Wobei es sich um eine umbennate fbclient.dll handeln könnte.

Hat der Benutzrt Schreibrechte im Verzeichnis?

[haentschman]

die embedded DLL kann auch mit dem Server. Ich würde auch auf fehlende Schreibrechte tippen.

:hi:

[hanspeter]

Zitat:

Zitat von haentschman

die embedded DLL kann auch mit dem Server. Ich würde auch auf fehlende Schreibrechte tippen.

:hi:

So in der Richtung wird es wohl was sein.
Auch wenn ich beide Programme mit Administratorrechten starte kommt der Fehler.
Ein Programm, egal welches, funktioniert mit der Datenbank problemlos.
Jeweils das danach gestartete Programm generiert die Fehlermeldung.
Inzwischen weis ich, das der Fehler nur unter Vista auftritt. Unter XP und W2000 funktionieren die Programme.
Ich habe auf dem Entwicklungsrechner eine saubere Firebird-Installation und alles was in Richtung Interbase geht, gelöscht.

Gruß
Peter

[Bernhard Geyer]

Ist bei beiden programmen die Virtualisierung abgeschaltet (Erweitertes Vista-Manifest)?
Tritt der Fehler auch auf wenn beide Programm unter W2K/Vista von einem User gestartet werden welcher nur in der Grupper "Benutzer" oder "Gäste" ist (so das dieser auch keine Schreibrechte unter C:\Programme\ hat)?

[hanspeter]

Zitat:

Zitat von Bernhard Geyer

Ist bei beiden programmen die Virtualisierung abgeschaltet (Erweitertes Vista-Manifest)?
Tritt der Fehler auch auf wenn beide Programm unter W2K/Vista von einem User gestartet werden welcher nur in der Grupper "Benutzer" oder "Gäste" ist (so das dieser auch keine Schreibrechte unter C:\Programme\ hat)?

Der Fehler tritt auf, egal mit welchen Rechten ich das Programm starte.

Im Programm:

Delphi-Quellcode:

IBDacConnect.Server := 'localhost'  oder 127.0.0.1 oder PC Name
IBDacConnect.Database := 'C:\Programme\Test\Db.fdb'
IBDacConnect.Connect; <-- Hier tritt der Fehler auf.

Ich habe das Programm jetzt erst mal unter XP am Laufen.
Das ist ein altes Programm, dass alle eigenen Informationen und Daten in Unterverzeichnissen des
Programmverzeichnisses gehalten hat.
War eigentlich praktisch. Das Löschen des Verzeichnisses hat das Programm rückstandsfrei entfernt.
Im Moment bin ich dabei die Datenhaltung umzustellen und schön quer über die Platte zu verteilen.

Gruß
Peter

[haentschman]

Guten Morgen... :hi:

läuft der FB Server als Dienst oder Anwendung. Vieleicht hat ja der FB Server keine Schreibrechte :gruebel:

[hanspeter]

Zitat:

Zitat von haentschman

Guten Morgen... :hi:

läuft der FB Server als Dienst oder Anwendung. Vieleicht hat ja der FB Server keine Schreibrechte :gruebel:

Der Server läuft als Dienst.
Da wird wohl UAC oder die Verzeichnisvirtualisierung dazwischen funken.
Ein Unterschied gibt es noch.
Eines der Programme ist in Delphi 7 programmiert und die weiteren Programme in D2009.
Das D7 Programm greift über IBObjects auf FB zu und die neuen Programme über IBDAC.

Gruß
Peter

[hanspeter]

Jetzt wirds ja ganz verrückt.
Der Fehler tritt nur auf, wenn eines der gestarteten Programme über IBObjects auf FB zugreift.
Ich bin wie bereits vorher erwähnt gerade dabei, Ibobjects durch IBDAC abzulösen.

Ich starte das D7 Programm mit Ibobjects und starte ein beliebiges weiteres Programm mit IBDAC.
Der Fehler tritt auf.

Ich starte beliebig viele Programme die über IBDAC auf die gleiche Datenbank zugreifen und der Fehler tritt nicht auf.
Ein 1,5 Mio Quellzeilenprogramm ist nicht so schnell in der Datenzugriffsschicht umgestellt. Der Fehler dürfte sich aber dann
selbst erledigen.

gruß
Peter

[hoika]

Hallo,

was passiert,
wenn das Programm mit seinen ganzen Verzeichnissen nicht unter Programme steht ?


Heiko

[hanspeter]

Zitat:

Zitat von hoika

Hallo,

was passiert,
wenn das Programm mit seinen ganzen Verzeichnissen nicht unter Programme steht ?


Heiko

Aus der bisherigen Erfahrung vermute ich, daß das funktioniert.
Diese Variante kann ich leider nicht prüfen, da die Pfade in dem Altprogramm fest verdrahtet sind.
Ich habe zwar noch den Uraltstand in der Versionsverwaltung, habe damals aber nicht den Orginalzustand aller Componenten gespeichert.
Dadurch ist das Programm auf dem Stand 2002 nicht mehr compilierbar.
Dazu müsste ich auch noch ein altes Delphi installieren, da Ibobjects auf Auslieferungsstand Frühjahr 2007 stehen geblieben ist.
Die Erweiterungen von FB2.1 sind bis zum heutigen Tag noch nicht eingeflossen.
Für Q4 2008 war auf der Webseite zwar eine Anpassung auf D2009 angekündigt.
Der Istzustand ist jedoch bis zum heutigen Tage unverändert. Ich gehe deshalb davon aus, dass IBObjects tot ist.
Selbst wenn jetzt noch eine Anpassung an D2009 erfolgt, lässt das für die Zukunft nicht viel Hoffnung.

Gruß
Peter

[TBx]

Zitat:

Zitat von hoika

was passiert, wenn das Programm mit seinen ganzen Verzeichnissen nicht unter Programme steht ?

Zitat:

Zitat von hanspeter

Aus der bisherigen Erfahrung vermute ich, daß das funktioniert.
Diese Variante kann ich leider nicht prüfen, da die Pfade in dem Altprogramm fest verdrahtet sind.

doch, kannst Du.
nutze die aliases.conf!
Dein alias kann durchaus c:\programme\DeinProgramm\DeineDatenbank.fdb heißen.
Dadurch kannst Du das Ganze mal in einen Pfad verbiegen, wo jeder definitiv alle benötigten Rechte hat.

Btw: Arbeitest Du sowohl in der D7-Version als auch in den D2009-Programmen mit entsprechenden Manifesten?

Gruß

Thomas

[hanspeter]

Zitat:

Zitat von TBx

Btw: Arbeitest Du sowohl in der D7-Version als auch in den D2009-Programmen mit entsprechenden Manifesten?

Thomas

In D7 habe ich kein Manifest verwendet, in D2009 schon.
Mit der FB Config probiere ich das mal aus.
Hat allerdings nur noch akademischen Wert, da in der Neufassung die Pfade anderst angeordnet und
IBObjects als Zugriffsschicht abgelöst sind.

Gruß
Peter

[Jens Hartmann]

Hallo zusammen,

ich muss mich hier mal kurz nachfragen. Ich habe seid einiger Zeit den selben Fehler in meinem Programm. Bislang konnte ich immer mit IBExpert und meinem Programm auf die DB zugreifen. Jetzt geht es nur noch mit einem der beiden.

Diesen Thread hier habe ich gefunden, allerings bringt er mir noch keine richtige Lösung. Hat jemand noch eine Idee, was ich geändert haben könnte?

Gruß Jens

[mkinzler]

Verwendest du vielleicht eine embedded Client? Wie sieht der connection string aus?

[Jens Hartmann]

Eigenlich nicht. Ich nutze die fClient.dll mit Firebird2.1 und habe in meiner Komponente in meinem Programm folgenden Database eingetragen: LOCALHOST:PSUser
Dieser Alias ist in der aliases.conf auch richtig deklariert.

Gruß Jens

[haentschman]

Zitat:

Ich nutze die fClient.dll mit Firebird2.1 und habe in meiner Komponente in meinem Programm folgenden Database eingetragen: LOCALHOSTSUser

...das sagt aber noch nicht aus, ob du mit Server oder Embedded arbeitest. Das ist vom HOST abhängig. Wenn du als Host LOCALHOST eingetragen hast solltest du mit dem Server auf deiner eigenen Maschine arbeiten können. Ist der Host leer arbeitest du in Verbindung mit den Embedded DLL´s als "Einzelplatz". Da kann nur einer auf die DB zugreifen.

[Jens Hartmann]

Wie kann ich das denn dann rausfinden. Es hat ja eigendlich immer funktinoiert.

Gruß Jens

[haentschman]

Welche Zugriffskomponenten benutzt du ? Ich glaube du hattest Zeos ?

[Jens Hartmann]

Jawohl, ich arbeite mit ZEOS

[haentschman]

zeige mal die Properties:
- Host
- Database

[mkinzler]

Wie groß ist/sind die Dll(s)?

[Jens Hartmann]

Die dll ist 440K und im Anhang befinden sich die Properties

Gruß Jens

[DeddyH]

Du hast ja auch keinen Hostname eingetragen.

[mkinzler]

Fülle Hostname aus ( localhost bzw. 127.0.0.1)

[haentschman]

Da siehste, daß Host leer ist. Damit arbeitest du mit der Embedded Version. Zufällig hast du auch die Embedded DLL´s.

Der Server läuft ? Dann schreibe bei Host localhost oder den Rechnernamen rein. Im IBExpert Remote und bei Host localhost oder den Rechnernamen rein. Dann sollte es gehen.

PS: TransactionsIsolationLevel... besser ist tiReadCommited

[Jens Hartmann]

Das ist seltsam, den Hostnamen hatte ich noch nie eingetragen und trotzallem hat alles funktioniert. Der Hostname(LOCALHOST) wird ja eigendlich auch in der Database schon angegeben. Wie gesagt, ich habe auch an meinem Programm nichts geändert. Es muss irgendwie mit der DB zusammenhängen.

Gruß Jens

[haentschman]

Zitat:

Das ist seltsam, den Hostnamen hatte ich noch nie eingetragen und trotzallem hat alles funktioniert.

...ja gut aber nie mit mehr als 1 User gleichzeitig auf die gleiche DB. Ist unmöglich.

Zitat:

Es muss irgendwie mit der DB zusammenhängen.

...glaub uns einfach :zwinker:

[Jens Hartmann]

Ich glaube Euch. Aber es ist echt so. LOCALHOST stand da nie und ich habe auf die DB mit meinem Programm und mit IBExpert zugegriffen.

Im Anhang mal die aktuellen Einstellungen. Es geht aber trotzdem nicht.

Gruß Jens

[mkinzler]

Dann war es aber ein Nicht-embedded Client. Dort wird, wenn der Hostname leer ist, ein lokales Verbindungsprotokoll verwendt, bei der embedded-Variante greift dasnn die integrierte Serverinstanz direkt auf die Datei zu.

[haentschman]

Tasten wir uns doch mal langsam ran...

- läuft der Server ? (Taskmanager oder Dienste)
- bei Database mal den Absoluten Pfad zur DB aus Serversicht incl. Dateiname rein (Bsp. C:\Test\Test.fdb)

[Jens Hartmann]

Also irgendwie steh ich mir auf der Leitung.

Ich habe eine Firebird Server 2.1 installiert. Und habe bislang über beide Programme auf die DB zugegriffen. Wenn ich jetzt nicht mehr darauf zugreifen kann. Was habe ich dann geändert.

Wie muss bzw. soll ich das alles denn dann richtig einstellen. Und was muss ich eventuell tauschen.

Der Server läuft als Dienst. Den Pfad habe ich jetzt eingetragen und jetzt kommt folgenden Fehlermeldung.

Gruß Jens

[haentschman]

kann die Zeos 6.6.4 schon FB 2.1 ? dann stelle das mal als Protokoll ein.

Ansonsten ist das kein Hexenwerk.
- Server muß laufen
- Host eintragen
- Pfad zur DB aus Serversicht
- PW und User
- Connect und fertig.

Die Client DLL müssen natürlich zur FB Version passen.

Was macht den IBExpert mit den Einstellungen ?

[mkinzler]

Passt der Client um Server?

[Jens Hartmann]

Nein, kann Sie leider nicht. Jetzt kann ich mir was vorstellen. Ich hatte bislang den Firebird Server als V2 und V2.1 installiert. Besser gesagt. Ich hatte mal V2, dann irgendwann aufgerüstet. Der Ordner von V2 bleibt allerdings beim deinstallieren bestehen. Diesen habe ich vor kurzem gelöscht.

Könnte es eventuell damit zusammen hängen.

Gruß Jens

[Jens Hartmann]

IBExpert läuft überigens mit diesen Einstellungen. Ich muss mal suchen ob es eine aktuelle ZEOS gibt.

Gruß Jens

[haentschman]

im IBExpert gibst du ja an, welche Client DLL verwendet werden soll. Kopiere diese mal in deinen Programmordner. (zum Testen) Dann sollte dein Programm die gleiche DLL benutzen wie IBExpert. Damit können wir die DLL als Fehlerquelle identifizieren oder ausschließen.

[Jens Hartmann]

Das habe ich bereits gemacht. Ich glaube ich muss mal ein wenig die Augen zu machen und morgen frisch an den Start gehen. Das Denken fällt aufeinmal so schwer.

Danke schon mal, ich melde mich morgen zurück.

Gruß Jens