Error 3804 Cannot find session

[ursamajor]

Did someone ever have a Sql error 3804 Cannot find session?

A customer of ours has this allmost every day on several clients (windows XP).
It usually appears when a user wants to exit our program at the end of the day.
All our other customers don't have this problem.

If more info is needed, I'll provide!

[Mike Vandine]

This is a general error and normally just means that the communication link between the server and the client has broken. You might have the customer do some hardware checks on their network cards.

[ursamajor]

Yesterday I went to another customer with the same problem.
I found nothing that could explain this error.

If a network connection is interrupted, I get a 9268 or 9024 error. I pulled the plug from the NIC, disabled the NIC and tried some other things, but I could not reproduce this error.

Is there any more information about this "cannot find Session"? Which session is meant?

[Mike Vandine]

Is the SQLBase server still up?
Did it come down and get restarted automatically (i.e. a service automatic restart)?
Is there any entry in a file called fail.sql (in the SQLBase runtime directory)?
When the user disconnects at the end of the day, were they 'not working' for a while, i.e. was there a period of inactivity? This could indicate a setting on the physical server itself that times out.

Can you send the server's sql.ini file?

[ursamajor]

The sqlbase was still running.

I saw the customer reproduce it once, after working with the program for a couple of minutes and then closing it.
Sometimes it occurs also when printing a QRP with the program.
So they work with the program and after like 5 minutes it throws the error.

What setting on the physical server could be timed out if there is a period of inactivity?
I guess that's still something to look for, because of the error that occurs after some inactivity, if it's only 10 minutes or so.

The fail.sql is not present and the eventviewer does not give clues...

All the powersave settings have been turned off.

The sql.ini is the same al all our other customers, like:

Code: Select all

;
; Gupta Technologies, LLC 2003
; SQLBase INItialization file
;

[win32client.comments]
;
; Win32 
;--------------------------
; Use this section to specify Win32 client workstation parameters  that  
; are independent of the communications protocol(s) being used.
;
; This section is for the Win32 client workstations. Here you will specify
; the COMmunication DLL(s) that the Win32 application(s) intend to use.
; Use the following protocol(s) to connect to the specified SQLBase product:
;
;	comdll		SQLBase target
;	------		--------------
;	sqlapipe	LOCAL database using Anonymous Pipes
;	sqlws32		REMOTE database using TCP/IP (WinSock)
;	sqlspx32	REMOTE database using IPX/SPX (Win32 Novell Client)
;	sqlwsspx	REMOTE database using IPX/SPX (Win32 Microsoft Client)
;

[win32client]
; ----------------------------------------------------------------------
; Windows client
; ----------------------------------------------------------------------

clientname=COMPUTER2
clientruntimedir=C:\Program Files (x86)\UNIT4\UNIT4 Multivers\Bin\
setzerolengthstringstonull=1
secureapi=0
negotiateapi=0

[win32client.dll]
comdll=sqlws32
;comdll=sqlapipe
;comdll=sqlws32
;comdll=sqlodb32
;comdll=sqlwsspx
;comdll=sqlspx32
;comdll=sqlntnbi

[win32client.apipe]

[win32client.ws32]
serverpath=MVSERV,localhost/*

[win32client.spx32]

[win32client.wsspx]

[win32client.ntnbi]

[dbntsrv]
servername=MVSERV,sqlws32
ANSIJoinSyntax=1
cache=128000
usecmcache=0
readonly=0
password=sysadm
oracleouterjoin=0
partitions=0
secureapi=0
batchpriority=1
EXTDLL=sqlfunc.dll
LOGDIR=C:\ProgramData\UNIT4\UNIT4 Multivers\Log\
TEMPDIR=C:\Program Files (x86)\UNIT4\UNIT4 Multivers\Temp\
DBDIR=C:\ProgramData\UNIT4\UNIT4 Multivers\Data\

DBNAME=MVLSYST,SQLWS32
DBNAME=MVLMAIN,SQLWS32
DBNAME=MVL99998,SQLWS32
[dbntsrv.gui]

[dbntsrv.dll]
comdll=sqlws32

[dbntsrv.ws32]


[dbnt1sv]
; ----------------------------------------------------------------------
; Windows desktop
; ----------------------------------------------------------------------

servername=MVLOCAL,sqlapipe
ANSIJoinSyntax=1
cache=4000
usecmcache=0
password=sysadm
oracleouterjoin=0
partitions=0
secureapi=0
batchpriority=1
EXTDLL=sqlfunc.dll
readonly=0

DBDIR=C:\SQLBase850
LOGDIR=C:\SQLBase850
TEMPDIR=C:\Tmp

DBNAME=MVLSYST,SQLAPIPE
DBNAME=MVLMAIN,SQLAPIPE

[dbnt1sv.gui]

[dbnt1sv.dll]
comdll=sqlapipe

[dbnt1sv.ws32]

[dbnwsrv]
; ----------------------------------------------------------------------
; Novell Netware 
; ----------------------------------------------------------------------

servername=MVSERV,sqltip
ANSIJoinSyntax=1
cache=32000
password=sysadm
oracleouterjoin=0
partitions=0
secureapi=0

DBDIR=C:\SQLBase850
LOGDIR=C:\SQLBase850
TEMPDIR=C:\Tmp

DBNAME=MVLSYST,SQLTIP
DBNAME=MVLMAIN,SQLTIP

[dbnwsrv.dll]
comdll=sqltip.dll
;comdll=sqltsp.dll

[dbnwsrv.tsp]

[dbnwsrv.tip]

[odbcrtr]

[Mike Vandine]

If there was a failure after 5 minutes, then it's got nothing to do with a timeout on the server, etc.

What version of SQLBase are you using? The SQL.INI file that you've shown seems to be *very* old! It includes Novell setups using SQLTIP protocols which we haven't used for *ages*.

Do you actually USE the single-user version, using APIPE and the Novell server?

[ursamajor]

Right

Well, we use sqlbase 11.5 sp3. The Novell entries are enherrited from the time when we used older versions of sqlbase.
This customer uses a sqlbase server. Other customers use the desktop version.
I guess this sql.ini isn't much of a problem because of all our customers, only 2 have this problem. Since we don't understand whats going on exactly, we can't help them fix this problem, or that we adjust our software.

So, there's no timeout issue;
Can't match the date/time of the error with anything in the eventviewer;
There's no fail.sql log entry;

We're getting somewhere by knowing what's not an issue here

The "session" mentioned in the error, is that a windows networksession or a session from sqlbase?

[Mike Vandine]

Hard to say...

OK. Modify the sql.ini for the server to start up a log file. In the [dbntsrv] section, put in a line:

log=filename.txt

Then on the SQLBase Console, set the display level to 2 and timestamps on. Now restart the server and wait for the event to happen again. When it does, drop the server, take out the log= line and set the display level back to 0.

Have a look at the log file to see if there is another error that happens before the 3804. That will be the *real* error!

Mike

[ursamajor]

Tnx, I'll try that.

[ursamajor]

I found a partial reproduction:

Client server environment.
Start sqltalk
connect island;

open the commandprompt as administrator
Execute the following commands:
ipconfig /release
ipconfig /renew

- in the console on the server you can see that the connection still exists

In sqltalk:
disconnect all;
- Now you get an sql9024 error
disconnect all;
- all cursors are disconnected
Connect island;

Now you get the 3804 error each time you connect.
You have to start sqltalk again to sucessfully connect again.

With our application I get sql 3806, so there is some difference...
Could it be a virusscanner or a firewall (like avg) that can cause this?

[Mike Vandine]

When you lose the network connect, the 9024 is given and the SQLTalk session link is permanently broken. You will *always* get the 3804 error.

I think with an application you can check for the disconnection (by checking for the 3806) and doing a call to the API I think it's sqldon() and sqlinit(0).

You might do a search on the forum for sqldon...

[FRBhote]

Wonder what

ipconfig /release
ipconfig /renew

does? Does it change the ip address? If so then you cannot access further from the client - it expects the same ip address that it connected with.

[ursamajor]

In my case it dropped the ip adress, and with the renew it got the same ip adress.

[tfahey]

We are also tracking this 3804 error as it has become quite a problem at some client sites.
Here is a summary:
it appears to be a problem caused by changes in the implementation of TCP/IP traffic across Windows Server 2008, Windows 7, certain new NIC cards or routers. At first we thought it happened on servers that had two nic cards installed, but we ruled that out. Now we are focusing on two areas with the help of network engineers at clients sites:
1) IP v4 versus IP v6 and the default settings for the various pieces of equipment found on modern servers.
2) Disabling the Proxy ARP on Cisco ASA routers.

Ursamajor, what is the OS on the Server and the workstations that have this problem?

We will post any findings...
Tom Fahey
HAB Inc

[ursamajor]

Wow! Glad we are not the only one!

The client is Windows 7 and the server SBS2008.
They have an unmanaged switch in the network, but they do have IPv4 and IPv6 in the DHCP configuration. But this configuration is beyond my knowledge...
I can give them your experiënce so they can have a look at it.
I'll also consult a system engineer at our site!

Thanks!