help.net


Musing on .Net

News





hit counters




Open source CMS

Technorati

My blog

Irish blogs

Locations of visitors to this page Get Chitika eMiniMalls

.Net useful

Blogs I read

PocketPC

SQL

Usability

General network error. Check your network documentation.


Does somebody has seen this message after an ADO.Net update on a database ?

General network error. Check your network documentation.

I work on a laptop, SQL seems to work fine for all my projects, and then suddenly after some code (very classic )I receive randomly this message ‘General network error. Check your network documentation.’


I say random because it’s not really all the time. If I refresh the web page, I can make it working sometimes.

For the moment to progress in my code, I just embedded my SQL update helper ( I use Data Block Application) in a try catch finally.

But obviously it’s not really ‘clean’.

Thanks for some help.

UPDATE:

The problem seem to happen if I create a datareader after an update by SProc.

I also found a KB about this. I applied the solution proposed, no better success.

In the document, MS talk about the confuion that SQL 2000 has if the name of the SQL instance has uppercase and lowercase in the name.

Posted: Jul 23 2003, 09:04 PM by help.net | with 30 comment(s)
Filed under:

Comments

Rand() said:

Yes, have seen it regularly, google shows some chatter on the newgroups about the same but no idea what the source is.
# July 23, 2003 11:19 AM

Paschal said:

The problem is this seems to be random.

And not really explicit error message !
I will probably try using my development server to see if this has something to do with my SQL installation.

# July 23, 2003 11:25 AM

TrackBack said:

heLP .Net Blog
# July 23, 2003 4:04 PM

Exar said:

I will second the randomness of this error. I have a production server that kicks it to me every so often, and I know that one of our customers had a bad experience, and for no reason.

I always close my dbase connections, and it happens on various pages.

M$ should fix it.
# August 11, 2003 12:53 PM

hamish.ahern@REMOVETHIStrustpower.co.nz said:

I also am getting this erro, and it only does it on some particular queries, seems tied to the execution plan, because if you alter the query to return the same records but using different execution plan the error goes away. one suggestion that sometimes easily changes the execution plan is to use an ORDER By clause. please post the MS KB article if MS have decided to fix this bug that wont allow production environments to exist on their software.
# August 24, 2003 9:53 PM

hamish.ahern@REMOVETHIStrustpower.co.nz said:

I fixed my problem. I found by accident that by change my cmd.CommandTimeOut = 0 to anything but zero fixed stopped the error from occuring on adapter.fill(ds)
# August 24, 2003 11:30 PM

mike w said:

setting the timeout to anything but zero totally fixes it. thanks a ton!!!!!!!
# October 8, 2003 3:36 PM

drydo said:

I don't necessarily think its related to the command - but the way the dotNET Data Provider handles the connections, i.e. through connection pooling.

Try using the attribute, "pooling=false;" in your connection string and check out 'connection poling' in the dotNET for all the gumbo.
# January 19, 2004 12:17 PM

Chas G said:

I experienced this error after a DB upgrade from SQL Server 7 to SQL Server 2000. The fix for me was to change my system DSN to use TCP/IP and force the DSN to change the default database to the correct DB (instead of master or whatever it was).

This had to be done for all of my DSNs, and it fixed this error for all of my sites/apps. I can't guarantee it has anything to do with your problems, though. Worth a try, perhaps.
# January 29, 2004 4:59 PM

Song said:

I tried to set the commandTimeout = 90, but the problem was not totally resolved for my server.
# January 30, 2004 1:32 PM

SONG said:

I read from another site. I tried the method provided there. I added to the connection string "POOLING=FALSE", and it seems that my problem is solved. Before this, I tried to set commandTimeout = 90, or using an oleDb commaned, and set its time out to be 90, neither completely solved my problem. But it seems that the "POOLING=FALSE" worked for my case. I am using sql server 2000. I am not sure the version of my ADO.net.
# January 30, 2004 1:50 PM

KShier said:

anybody seen further info or links on this problem? I encounter it intermittently as well. Two days ago was the first time (in a 6 month project) that i saw it. Yesterday, didn't see it. This morning, it's back. :(

I am going to try the connection pooling trick for now to see if it works, but what if your app needs to use connection pooling?!
# February 5, 2004 10:55 AM

Paschal said:

What I discovered to fix it is to add Max Pool Size=100; in the connection string.

100 is the size of the pool but maybe you can play with this value.

Other thing, Index service can create a lot of issues so the best is to go to the Index Services and remove the drive where the .Net temporary folder is located from the catalog list.
Works better for me now ;-)
# February 5, 2004 11:29 AM

KShier said:

will check it out thanks!

I wonder, though... once you reach 100 conns in the pool, will the issue re-manifest?

also, now that I have learned that the connection pool is kept on the client-side, I think I can safely use 'pooling=false'.
# February 5, 2004 2:12 PM

Paschal said:

I am not sure it's a good idea to turn off the pooling feature, regarding the performances.

My issue is also the fact that I had surely forgot to Close a connection somewhere in the code, and this obviously create this problem.

What I am sure however is the tip about Index Service.

Because what does Index Service is to lock files and of course doing so on such temporary files like the ones in .Net Temporary folder is not a good idea.
# February 5, 2004 2:24 PM

Leo said:

I am havving grave problems with this.

I have an Db server with SQL 2000 and another with SQL 7.

They worked well until friday, since then i received the message error! and i cant make the server 7 see the server 2000.

Does anybody could help me?
# February 18, 2004 1:43 PM

jary said:

i experienced this using sql query analyzer. i am using sql server 2000. any ideas how i can fix this? thanks in advance
# March 9, 2004 4:43 AM

Paschal said:

The only way I found to fix it is to add pooling=false in your connection string. Not the best but it works for now.
# March 9, 2004 4:57 AM

jary said:

hi paschal, thanks for the suggestion :) but i guess, that won't work for me, coz i'm just using ms sql query analyzer. i checked my odbc properties and the connection pooling is disabled.

i am only running a simple query with an order by clause in a sql query analyzer. if i remove the order by clause, the query works fine.

any other ideas? :)
# March 9, 2004 9:52 PM

jary said:

ei, i found out that if i changed my order by column, the query works fine. the weird thing is, my original order by column is also included in my select fields
# March 9, 2004 10:43 PM

Vinod said:

Even we are facing the same problem in production environment. We get this error when we are trying to insert records in our table. The table has NTEXT column. We are facing this problem once in 2 months. We are still not able to find out what can be the cause.
# March 10, 2004 3:49 AM

Ixra said:

Hello,

Yeah, here we've got the same weird, weird error. Indeed, we are just trying to create a ODBC data source to a remote SQL server, and sometimes, the server is succesfully found, but sometimes it isn't. This is very weird since we do the same steps in order to create the ODBC DNS but is completely unpredictable if it will work or not.

Some advice out there?? I tried updating the MDAC but I really don't think this will fix the problem, since we've got other SQL Servers that work fine without the MDAC update, so it seems to be vooodooo thing.

WEIRD and obnoxious!
# March 12, 2004 10:59 PM

Bill said:

Hello All,

I was doing some work on an XP Pro / MSDE laptop and consistently got this error message when I was doing alot of calls to an insert sproc. The laptop also had Norton Internet Security on it. When I disabled that, the message went away.

Before I thought of turning that off, I had SQL Trace running on another machine tracing the MSDE on the laptop. Right before I would get the dreaded 'network' error message, my sproc duration in the trace would spike from around 10-30 all the way into the 10,000's.

I wonder if any other type of intrusion detection software can cause this issue?
# March 23, 2004 6:01 PM

grr said:

oh my god this is why i hate ms technology. stupid random errors with solutions that don't work where the error sometimes happens and then you look the other way and it does
# March 24, 2004 10:31 PM

deep said:

general network error when trying to run a jdbc prgram .help
# April 22, 2004 1:41 PM

deep said:

general network error when trying to run a jdbc prgram .help
# April 22, 2004 1:46 PM

haz said:

have been getting this error messages for quite some time. checked the connection files n all seems to be fine.the error goes away when refresh the page....
# April 23, 2004 3:33 PM

uptaphunk said:

Have been experiencing this error intermittently. It seems to happen consistently for a few tries and then goes away and then may or may not appear for hours or days. It occurs on the DataAdapter Fill statement. I'm pretty sure I'm closing all my connections as I'm using the

using (SqlConnection conn = new SqlConnection(connectionString))
{

}

syntax.
# May 11, 2004 6:40 PM

mary said:

same thing here, intermittent general network error with SQL Server 2000 and asp.net ADO.NET new SqlConnection. The calling asp.net page creates an ojbect which opens the connection over and over and relies on the destruct method of the database object to do the closing so I am assuming our problem is related to this but I have not been able to reproduce it reliably so I can't be sure this is the cause of the problem.
# May 12, 2004 1:08 PM

Bjorn said:

CAUSE
In the current design, after an application role is enabled on a client connection to SQL Server, you cannot reset the security context of that connection. Therefore, when the user ends the SQL Server session and disconnects from the server, the session is not reusable. However, OLE DB resource pooling returns the closed connection to the pool, and the error occurs when that connection is reused and the client application tries to reset the connection's security context by calling sp_setapprole again.
WORKAROUND
The only available workaround is to disable OLE DB Resource Pooling, which ADO uses by default. You can do this by adding "OLE DB Services = -2" to the ADO Connection string, as shown here: 'For SQLOLEDB provider
'strConnect = "Provider=SQLOLEDB;server=SQL7Web;OLE DB Services = -2;uid=AppUser;pwd=AppUser;initial catalog=northwind"

' For MSDASQL provider
'strConnect = "DSN=SQLNWind;UID=Test;PWD=Test; OLE DB Services= -2"


Pooling can be disabled for the SQL Server .Net Data Provider by adding "Pooling=False" to the connection string.

The solution on MSKB:

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q229/5/64.asp&NoWebContent=1
# May 24, 2004 1:33 PM