At 05:01 AM 26/08/2005 +0000, you wrote:

> > >
> > I may have misspoken: netstat does NOT show/list port 3050 as being
> > active. I would even suppose that that is causing the connection to
>be
> > refused.
>
>That would do it.
>
> > But what can I do (some script in init.d?) to have 3050 be
> > active?
>
>One of the linux gurus here may have to help you. I imagine the
>service / daemon is not running but I am not sure why isql would then
>work. It works differently to windows so I can't help much more sorry.

Well. I'm not Linux guru, but...I still use Linux OK. (I'm not a Windows
guru, either...) From the fact that you were able to make a local
connection, I can tell that you are not using Superserver, but Classic.

Classic needs to have the xinetd daemon running to make remote server
connections. Doing ps -ax |grep xinetd will show you whether it is. If you
don't see an entry containing fields like xinetd -stayalive -reuse...etc.
then it's not running.

If xinetd is running, then netsat -an (run in the gnome or kde console, so
you can scroll back to look at the UDP ports) will show port 3050 in LISTEN
state - as long as the firebird script /etc/xinetd.d/firebird is there.

Supposing it is, the next thing you have to do is provide a valid TCP/IP
connection string if you want to make an xinetd connection. It has one of
the following formats:

hostname:/path/to/database/filename
or
nnn.nnn.nnn.nnn:/path/to/database/filename

If you do this correctly and you still get a 111 error then the most likely
thing is that the firebird user (a Unix user created by the installer
script) doesn't have permissions to open the database file. Try doing ls
-l on the directory and see who owns it and which group has permissions for
it. To work, it must be firebird:firebird on both the containing directory
and the file. The firebird user also needs execute permission on the
directory.

Since all of this is documented in the release notes, I won't go into more
detail.

./heLen