Don't know if it has anything to do with it, but on the client side they use Kaspersky antivirus suite... The firewall and some other options are disabled there.
We have seen virus scanning affect things like module loading(one program callng another), but have not seen it cause a disconnect.
I can confirm this issue in dependency with the "Kaspersky antivirus suite".
In the part of the Kaspersky firewall you have to check that the "Local Network" is "Trusted".
That was my solution, maybe it exists another.
Focus is now on the 'ARP Tables' (Address Resolution Protocal) used by all the components. It is noted that some Cisco switches default to 15 minute time-outs/refresh, but that event is not a hard time-out but a refresh of the address table. The client in Texas is going to up that setting to 60 minutes and will report back on what happens.
The clients are spending real $$$ on this issue. We need to get a resolution.
Mike,mvandine wrote: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...
How do I define the parameter for the sqlini function in TD?
The documentation just says that its a placeholder and must be zero.
They have turned off IP6 on the server NIC card and on some workstations. They have now increased the ARP Cache entry timeout to 60 minutes on the server. System still fails! Their IT person will further study the switch settings.
Anyone have any other ideas?
Are you also using 11.5?
There is a possibility that we could do a NETLOG, which captures *every* server execution and then we could replay that, looking at the results to see if there are any issues on the server side. However, this is *very* performance intensive at the site plus *very* labor intensive on our part to go through the log. This probably would not actually pick up the error if it's a comms issue and if you request this we might have to charge you for the engineer's time to check it.
Ursula, did you get any results from the log= entry in the sql.ini file? You said that you would try that, but you never let us know the results. Tom, perhaps you could try this.
Now on the SQLBase console, turn on timestamps and then set the display level to 2. When your customer reports that a 3804 occurs, have a look at the log file for around that time (search for 'err') and see if there is some backend error that is being reported. This could show what might be going on during the transmission.
The sites with the problem are Sqlbase 8.0. I can try the log file trick, but I need to be careful in slowing down the client's system as some of these sites really busy. I let you know if we catch any of these errors.
Our focus is now shifting back to Anti-virus software. See Enrico's post about "Kaspersky antivirus suite" as that seems to be the path we are now going down.
There has been a significant up-tick in reports of 3804 that correlate with IT people applying patches to their security software over the holiday. The lastest is a client that went from no previous episodes to daily interruptions after applying the latest upgrade to Trend Micros. We've got three sites now trying different settings on their Virus Scanning & Firewalls.
Comments are welcomed.
Sorry for the delay. The guy who couldlook at the log has been on vacation until Monday. I have forwarded this to him and am waiting for a response. He’s been gone for over 2 weeks, so has got a bit of catching up to do. I will let you know when I hear something.
Who is online
Users browsing this forum: [Ccbot] and 0 guests