Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ReadWrite problem From within VB app

Status
Not open for further replies.

majordog

Programmer
Joined
Jul 8, 2002
Messages
222
Location
CA

The circumstances are:

VB 6.0 application which uses ODBC.Connection to connect to, NT integrated authentication, SQL Server 2000 database. There are no firewalls to get through, as it's internal and uses the NT user login as the database login. This message appears randomly when running the application and is a fatal error as it causes the application to close completely.
I went and downloaded a newer version of the client library DBNETLIB.dll and placed it on the client. I read some help files that indicated this problem involves the communication betweenthe ODBC driver and this library on the client and another library on the server called Ssnetlib.dll. But, we are still experiencing the problem. As well, the speed populating the cbo boxes has realy slowed down as well as launching text files from within the code. Changing the connection from Access DB to SQL Server fairly recent and have been experiencing the problem ever since.
The exact error message we see is:

Run-time error - 2147467259(80004005):[DBNETLIB][ConnectionWrite(Send()).]General Network error. Check your network documentation.

I ran a profiler on the client but had no results useful in this case.
SQL Server is running on a Pentium 4, 1.60GHz, 525 KB Ram running Windows Server 2000 with SP3 installed.

I have been looking everywhere for something to help me solve this - Hard problem to track down - Any help much appreciated!!
 
Have you installed the latest SQL Server Pack SP3a or at least SP3 ?
 
MSDN documents a very similar error refer Q303120. If SQL server is set to use NT Fibres instead of threads. You should only use fibres under fairly specific conditions.

Problem was fixed in SQL server SP2

Use enterprise manager to check the server properties on the processor tab.

Maybe this helps but thats about it from me.

 
Hey - No, the processes are set for threads. And SP3 is installed. This only occurs on one client...I'm really banging my head against the wall onthis one.
 
>Hey - No, the processes are set for threads. And SP3 is installed. This only occurs on one client...I'm really banging my head against the wall onthis one

That suggest to me a flaky network...

Have you tried the usual eliminations?

[ul][li] New network cable from NIC to wall[/li]
[li]different data port in wall[/li]
[li]different data port on switch etc[/li]
[\ul]
It maybe something like that.

I would also check that that client is configured to use TCPIP as the protocol with SQL Client Network tool

Just soem thoughts, but maybe you should think of things other than your software!

Take Care

Matt
If at first you don't succeed, skydiving is not for you.
 
Yeah, the reason I haven't focused on the network is because the Network Admin assured me that it wasn't anything to do with his end...And I can't touch anything without his go ahead. So, I wanted to make sure that I'd checked everything my side of things to eliminate every possibility there.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top