We have had lot of experience with this #3806 error over the last few years. How do your clients workstations connect to the server? Is it a local connection, Citrix or TermServer? Is it thru VPN and if so what manufacturer makes the VPN product? We learned recently that SonicWall times out after 5 minutes of no TCP/IP activity. This can be changed however.
the clients connect to the server with a local connection, a simple LAN with TCP/IP. The error doesn't occur after a time of inactivity, but always in a chain of transactions. Other programs on the same client PC but without database activity continue running without problem.
The programs have several connections to distinct database. When a program has the problem, all connections are closed, also these without activity at the time of the first error.
I've tryed to disconnect my Laptop from our LAN, and I've got the same error when I've started a database action. But when I've lead the program running without database activity and connected the Laptop again, the program continued without error - a similar behaviour as at our customer.
But the administrator said, that there were no network events. Strictly speaking, I don't trust the super virtual hard disc with the database files. Could a hard disc problem cause this behaviour?
Thank you and best regards
In any event - The #3806 and #3804 saga we had was caused by Team Develope DLL's in the TD deploy directory. Mike Vandine can help you pursue that path. It is worth a try.
Generally if a client gets a #9024/#9020 then look to the network phyically going down. But if its a 3804 or 3806 its a problem with TD synchronizing with the DB Manager on established cursors.
If you were getting 3804 errors we have a fix for that starting with TD5.2 SP4. This was an error in finding the correct session when there was a possibility of duplicate sessions on the server. SB sometimes picked the wrong one.
I can send you a new DLL, but I don't know if that would really help with the 3806, which just says that the session connection was lost.
the version of the deploy directory of the client is 5.2 SP 3. I get a lot of errors 3806 and one 8010. Do you recommend me to try the SP 4? Or SP5? Or only to change the dll? My mail address is email@example.com
The super virtual hard disc is a raid 10 in a virtual environment. The adminstrator creates volumes from this big storage, or he also can increase the existing ones. The old administrator died last year, and now nobody knows, how it works. Only, that there are 7 layers. I don't trust it, since the volume for my database files is extremely slow, e.g. much slower as the simple hard disc of my laptop. And I had big problems to load my databases, but only to certain parts of the volume.
The new administrator said, that the PCs create several channels to the database server. If the problem occurs, one of the channels is closed, while the others are not affected. Now there is the question, who kills the session: the client program, the network ore the database.
May be, we should try the new dll. Which SP or only one dll?
Thank you and best regards
today the first error was 9010 - Session closed (and after this a lot of 3806). In the description there is the remedy:
"This notification can originate from SQLBase refusing a connection attempt due to an inappropriate level of security used in the transmission of messages between the client and the server. Check the SQL.INI declaration 'SECUREAPI' for both server and client."
I've never seen a 'SECUREAPI' key word in an sql.ini (I've checked both on the server and on the client). And the error wasn't caused by a connect, but by a select statement. Does this error number help us?
Thank you and best regards
The 9010 error is just a general networking error that says that the connection was lost. The description of the error (regardless of what it says in the 'remedy') is:
Reason: The session has been closed from either the local or remote computer.
Not really much help there, but it does explain the 3806 error. When a connection is interrupted with a 9010 the cursor 'chain' is broken and any further attempts to talk to the database using that cursor handle will fail, since the client session is no longer known to the server.
So, you really need to find out what in the network is breaking the connection. I doubt that this is anything set on the SQLBase server engine itself (nothing in the server's sql.ini file to limit the time for a transaction, etc.), so it could be a timeout happening in your network connection. There is certainly a network connection break there. Hmmmm. Perhaps you could also check if you have a virus checking application that is not behaving correctly.
; The number of database pages that can be cached in memory
; Pages are per server, and shared with all databases
; Recommended: at least 20000
; The default value for readonly is 1, which allows use of "read only" and
; "read committed" (RO and RC) isolation levels. Uncommenting "readonly=0"
; will disallow use of RO and RC isolation levels.
; To get process logging, specify a log file and display level.
; SQLBase supports communicating through named pipes. Named pipes
; support Windows network authentication and allows a client running
; on the same machine to find a server without explicit configuration
; Options are:
; namedpipes=No ; 0 - Named pipes not enabled
; namedpipes=Yes ; 1 - Named pipes are enabled for local and remote access
; namedpipes=LocalOnly ; 2 - Named pipes are enabled for local access only. Remote access is denied
Can you check the transport that you are using? Shows namedpipe=localonly. With a connection to the server, bring up the SQLBase Console (dbsrvgui) and set the level to 2, then look at the Server Status box. What is listed as 'transport'?
For God's sake, get rid of that sortcache= statement!
Who is online
Users browsing this forum: No registered users and 0 guests