Options
General Network Error
Brian Donahue
Posts: 6,590 Bronze 1
Hi Scott,
As far as I know there shouldn't be a problem even if you force protocol encryption on the server.
Have you tried connecting to the server using an alias configured in the Client Network Utility? That may weed out any network configuration problems caused by ADO .net choosing the wrong network library to connect to the server.
Please let us know if that works!
Regards,
Brian Donahue
Red Gate Technical Support
"Scott English" <nospam@nospam.com> wrote in message news:yQcIChkWEHA.3028@server53...
I'm getting a General Network Error when I try to compare. I've run a compare on these servers before without a problem. Not sure what changed. Here are the details.
a.. I can run a compare on my local SQL Server 2000 just fine.
b.. I can run a compare on my coworkers SQL Server 2000 just fine.
c.. I cannot run a compare on our shared development SQL Server 2000 or against our production servers. I can select the name of the server and then get a list of the databases in the drop down box (so I know the connection works), but when I click the Compare button, I immediately get an error message saying, "General network error. Check your network documentation."
The "problem" servers have hyphens in their names, e.g. DBDev-01. The servers that work do not have hyphens in the name. I have previously run compares against the "problem" servers, so I don't think the name is the problem. I also created an alias for this server called "DBDev" and still have the same problem.
The "problem" servers are configured to encrypt network traffic, that is, the Force Protocol Encryption checkbox in the Server Network Utility is checked. I believe that I have successfully run comparisons against these servers since the encryption was turned on, but it may be that my last successful comparison was prior to this.
I was running SQL Compare 3.1.5. Since I was having this problem, I just upgraded to 3.1.7. No help.
I have no problem whatsoever in connecting to these servers with any other programs.
As far as I know there shouldn't be a problem even if you force protocol encryption on the server.
Have you tried connecting to the server using an alias configured in the Client Network Utility? That may weed out any network configuration problems caused by ADO .net choosing the wrong network library to connect to the server.
Please let us know if that works!
Regards,
Brian Donahue
Red Gate Technical Support
"Scott English" <nospam@nospam.com> wrote in message news:yQcIChkWEHA.3028@server53...
I'm getting a General Network Error when I try to compare. I've run a compare on these servers before without a problem. Not sure what changed. Here are the details.
a.. I can run a compare on my local SQL Server 2000 just fine.
b.. I can run a compare on my coworkers SQL Server 2000 just fine.
c.. I cannot run a compare on our shared development SQL Server 2000 or against our production servers. I can select the name of the server and then get a list of the databases in the drop down box (so I know the connection works), but when I click the Compare button, I immediately get an error message saying, "General network error. Check your network documentation."
The "problem" servers have hyphens in their names, e.g. DBDev-01. The servers that work do not have hyphens in the name. I have previously run compares against the "problem" servers, so I don't think the name is the problem. I also created an alias for this server called "DBDev" and still have the same problem.
The "problem" servers are configured to encrypt network traffic, that is, the Force Protocol Encryption checkbox in the Server Network Utility is checked. I believe that I have successfully run comparisons against these servers since the encryption was turned on, but it may be that my last successful comparison was prior to this.
I was running SQL Compare 3.1.5. Since I was having this problem, I just upgraded to 3.1.7. No help.
I have no problem whatsoever in connecting to these servers with any other programs.
This discussion has been closed.
Comments
I think that in the alias you also need to specify the network library as 'Multiprotocol' if you're using encryption on the server; have you tried that?
Brian
"Scott English" <nospam@nospam.com> wrote in message news:dnvGT46YEHA.2468@server53...
Yes. It didn't help.
This shouldn't be caused by any network patches. This problem has been plaguing SQL Servers since the first DBA stood upright and discovered fire.
Of course the problem is that the error message doesn't exactly lend itself to a quick zero into the cause of the problem. Usually it's because the connection was terminated unexpectedly.
Trying a different network library (using a client network utility alias) works an awful lot of the time. Specifying TCP/IP over named pipes sometimes helps.