At 07:34 PM 23-08-02 +0000, you wrote:

>Hi,
>I have a problem with the Interbase/Firebird SQL-Server V 1.0
>I cannot connect to a database with a statement like this:
>
>ISQL> connect '/opt/interbase/examples/employee.gdb' user SYSDBA
>password
>masterkey;
>
>I get always the error-message:
>System failed, SQLCode = -902
>Cannot attach to password database

My databases are not stored in the /opt filesystem but in one named
/data. When I use your quoted syntax, the current directory of ~~isql~~
(/opt/interbase/bin/) gets prepended to the database path and I get your
error, viz. if I do

/opt/interbase/bin/isql '/data/employee.gdb' user sysdba password masterkey

I get

'Unable to connect to ''/opt/interbase/bin/data/employee.gdb''

(The quotes in the message are pairs of single-quotes, not double-quotes)

Notice how the path has been mangled!

If I do it without the quotes:

/opt/interbase/bin/isql /data/employee.gdb user sysdba password masterkey

I get
Database: /data/employee.gdb User: sysdba

>SQL

What surprises me is that isql actually accepts a local path without the
server name, viz.

localhost:/opt/interbase/examples/employee.gdb user sysdba password masterkey

The surprise is that it seems contrary to the documented instructions and I
guess this is the first time I tried to do a "local connect" on Linux
without including the server in the path. The server apps must have some
kind of macro that applies localhost: transparently.

>ISQL> connect '/opt/interbase/examples/employee.gdb'
>-> successfull connected
>In that case, I can execute statements like 'SELECT * FROM ...';, that
>means, the server itself works fine.

On Unix, root has some kind of special relationship with the server process
and in some places is allowed to login as root and be connected as
sysdba. (I've never been quite sure how this works but it's worth
documenting properly if I can find out...)

Also, if you have the ISC_USER and ISC_PASSWORD variables defined in your
environment (not recommended except on a development-only server) then you
don't need to supply user name and password to log in to any database.

>I get the same error, when I try to change the password with 'gsec':
>error: cannot attach to password database
> unable to open the database

When logged in as root I can do
...)# gsec -add blueeyes -pw u909star

and

...)# gsec -display

etc. etc.

Likewise, I can do

...)# gsec

and get into the interactive gsec shell, where I can do stuff like

GSEC> display

and

GSEC > add BENNY -pw sixducks

without problems.

>the server runs under RedHat linux V7.1 and the database isc4.gdb
>exists and is not corrupted and the user (root) has all the rights to
>access this
>file!

File access and database access aren't the same thing. It is the server
process that needs the filesystem rights. Users don't need (and should not
have) any filesystem rights.

Read up on isql and gsec in the OpGuide.

heLen