Well its always developer vs administrators, and for the life of me why wont they listen...? However now I must and hopefully someone can help. My need for this resolve is not to change the software which works, but to enlighten the administrators as to possible NOD32 conflicts, or perhaps another issue which I've missed.
In the following scenario I am stumped, and have never heard of anything like it.
The server (DNS (win2003) & sql 2000 sp3) has NOD32 enterprise running, my apps have been running on this environment for the last 3 years, however, for the last year and since NOD32 has been installed, a few very strange incidents have occurred.
1. Whenever this error occurs, users fail to connect to SQL server, the server connection string has to be altered from either server name to the server IP or vice versa. This is an intermittent occurance and can be anything from a few days to a few weeks between occurances.
To limit connectivity issues to a particular protocol, SQL only uses tcp/ip on port 1433. LMhost dont resolve any of these issues either.
2. Twice since the NOD32 installation (I do hope I am not blaming them unneccessarily) SQL communications has degraded over a period of time till a complete halt, (By degraded I mean point 1 above becomes more and more repetitive).
What I found is that when local network users no longer function, my terminal services users were still operational, the local network users could'nt comunicate via native drivers or odbc. In other words the drivers were functional in local only environment. The data server resides behind the linux firewall hence no port blocking is setup of the data sever.
My solution was to reinstall sp3, however does not explain the above errors,
If I am missing something, pray do tell, customer blames administrator, administrator blames me, I gotta blame someone or offer a solution cos hell knows no administrator is ever at fault.
In advance, excuse the digs if you're an administrator and many thanks
GDR...stumped!
There are many reports that some antivirus softwares are not compatible with sqlservr.exe. To prove this theory, can you try the following and log the result when your server is operational and malfunctioning. One of
(1) "ping servername" "ping serveripaddress", "ping -a sereripaddress",
(2) "telnet servername/serveripaddress 1433".
If any of above does not work, or the ipaddress is changed over the course, you should find if disable/uninstall NOD32 would help solve your problem.
|||It looks like Nod32 limits the number of concurrent tcp connections. searth "Nod32 limit connection" you can find some hint. It's strange that changing the server name to IP address (vice versa) can solve the problem for a period.What's the SQL error msg when you see the problem? When you see the problem, do all users from any machine on local network fail, or just fail on the server?|||
TCP/IP is still intact on the server, all ping or telnet responses are ok, it seems as if it is down to the drivers operating (somehow...) in a local mode when the problem presents itself.
The only problem with disabling the antivirus, as we know, users will infect the systems even be it inadvertantly. Another consideration is, I now have to wait till the next connection failure, and since the service pack has just been applied a week ago, I do not know when the next failure is going to be, so how long do we keep the antivirus off-line.
I have read an article on another resource that when installing NOD32 Ver2, the application binds to port1433, so I am checking logs for when the anti-virus updates (not the virus files but the application), perhaps there in lies a problem, there is a registry fix for this problem however when checking the reg, all is in line with the fix.
Thanks for the reply, but still in a bind....
|||Hi, I thought you were on to something there, then I remembered, there is also a .net app using remoting, the server side components handle all sql connections and route information/data/results etc back to the calling client, I wont go too far into that, but what this means is it is not a tcp connection limit as this application still functions, also is the fact that this app uses native drivers like my app does.
Getting back to my strange theory that it is as if the drivers are operational but local only. Also to support this, remember that the terminal server users remain operational, although only after ammending the server name to ip or vice versa.
I know I have mentioned this before, but when all the users could no longer connect, from a local network machine, I tried odbc directly and all to no avail, the only thing I did'nt try was to place the application components into a COM+ environment. Yet again this will only be a work around for an issue that has not been resolved.
|||Were you be able to run my recommended ping and telnet from any of your client machine when your client failed to connect to the sqlserver? Your post give me impression that you did not have chance so far yet. Also if you could share out the error message when your client start to fail, it will be of great help too.
Since both teminal server user and sqlserver user need to switch the server name to IP or vice versa in order to connect properly, I don't think sql server is the culprit. You might find fast solution by followup with your system admin and the NOD32 on this issue.
|||The ping and telnet test were carried out before I had SP3 reinstalled (tests done by admin), In terms of the SQL error, its the standard connection error : [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
As for NOD32 help with this, I have accessed their Forums and have found only one solution, uninstall NOD32, this according to my clients administrator is not an option. Unfortunately, the admin is of the mindset it can only be my app, although it worked fine and works fine on several other networks (all before admins existence at said problematic company.) If no solution is possible I will withdraw my software. The admin is also of the mind set that I should write a tcp databroker to work around this problem, yet again a work around and in this case to save the admin... as we all know a rewrite is not always possible when it comes down to application size etc etc etc.
Besides a VB6/.Net remoting hybrid would be simpler to write than trying to implement and reinvent the wheel when it comes to socket security, data encryption etc.
Thanks for the reply none the less....Still Stumped...
GDR
|||Since you are getting, [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied, and you are using TCP with default 1433 port, I would expect the winsock connect "(Connect()).]" to the server was failing. I am confused how "telnet servername 1433" could work. To uncover why your app is failing, you might want to experiment with ETW tracing, http://blogs.msdn.com/sql_protocols/archive/2006/08/04/688396.aspx. You can experiment it out. You need to use MDAC2.8 and add {BD568F20-FCCD-B948-054E-DB3421115D61} 0x00000000 0 DBNETLIB.1 in your ctrl.guid file.
|||
Many thanks however, perhaps we should simplify before we start stripping whats working,
1. Occasional connection errors occur, swop name and IP and OK again.
2. After prolonged connection errors, eventually all network comms fail, but not on the local machine, terminal server users still get to function, however may have to swop ip and name in app connection settings.
when point 2 has occured even ODBC fails to connect to server from network client, although c# remoting app on network client functions, this I can attribute to the connection taking place by the component on the server environment and that making the actual connection, which suggests tcp to be in working order else neither terminal services or remoting objects would function.
Somehow I keep coming back to driver/port external influence on these as too many other processes that rely on tcp remain functioning. I have installed (as a test) sql redis on some clients to ensure latest sql client connectivity tools, also SP4 on server.
Dont know what else to say except thanx for the input, I will be looking at the ETW trace and reply if results are favourable.
Thanx again.
|||Many thanks all for your input, the problem has'nt shown itself in the last few weeks however, now that this post has gone out its probably due to occur shortly...(murphy's law). If the problem arises again I will start resume with this thread.
I dont know if it was the service packs that resolved the issue, but all is quiet on the western front.
No comments:
Post a Comment