Subject Re: [IBO] Connecting problems on Linux
Author rsaegerde
--- In IBObjects@y..., Helen Borrie <helebor@t...> wrote:
> ** Events ** use a second connection and DML caching uses events.
Yes, it is what I mean.

> Just to confirm, the only setup where DML Caching causes the client
to fail
> to connect is this one. DML Caching works otherwise?
Yes, only DML caching and only on notebook. The SAME app and the SAME
database work on desktop with linux in very similar configuration.

> If it's any comfort, I have a WinNT client connecting happily with
> 1 SS on RedHat 7.2, with or without DML caching.
I have Win98 client connecting happily with Firebird 1 SS on Suse 7.3
with DML caching, too :-). As you say below, it is probably something
on my notebook linux, but what?

> Yesterday in IB-support you eliminated the "wrong client"
Yes, it cannot be a client problem. It works on the other linux
server OK, it works on Win98 SE "server" OK, and, very important, it
works in production environment on my client's network with W2K
server OK since 3 months.

> It's clearly a configuration problem - something is missing from
your Linux
> server setup on the notebook. Could we get more information...
> like - on your IB_Connection (just so we can see all the ducks)
> 1. What do have for the Server parameter?
What do you mean, server name? dbserver.

> 2. What is your *exact* Path string?
dbserver:/db/einkaufc.gdb (or other database names, but allways in

> 3. What is your Protocol entry?

> 4. What PasswordStorage property are you using?

> and, before you post back,
> 5. Confirm that your Linux server is not being seen from the Win98
> as a Samba share, i.e. confirm that the Path string points to a
location on
> the server's own physical filesystem.
There are no Samba shares, Samba is not running.

> 6. Examine your HOSTs entry on the Win98 client and tell us
> the server entry is there. dbserver

> 7. Check that the server entry is present in the /etc/hosts file
(a Linux
> server needs this as well if you aren't using DNS resolution)
Yes, I've checked it, OK.

> In a Linux shell, do a
> netstat -t to see whether the server is actually listening on port
netstat -a:
tcp 0 0 *:gds_db *:* LISTEN

Let me say once more: apps WITHOUT DML caching/events can connect and
run OK.

But wait, I have news:
after the client fails to connect, I cannot connect any more, not
with my apps, not with WISQL. Then I did "firebird stop" on
the "server", it takes allways long time after the conection error,
and during this time I called netstat -a again:
tcp 137 0 localhost:gds_db localhost:blackjack CLOSE_WAIT

What does it mean (blackjack sounds very ugly <g>)?

Thank you for your help,