--- 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

Firebird

> 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"

possibility.
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
dbserver:/db/...)

> 3. What is your Protocol entry?

cpTCP_IP

> 4. What PasswordStorage property are you using?

psNone

> and, before you post back,
>
> 5. Confirm that your Linux server is not being seen from the Win98

client

> 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

EXACTLY what

> the server entry is there.

192.168.1.111 dbserver.saeger-edv.de 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

3050
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,

Richard