Couls u email me if u got any clues
Sybase Engineering has reviewed Sybase bugs 263160, 277718 and
274111. After intense review and investigation, Sybase Engineering was
able to reproduce the problem with a simple C program outside of any
Sybase products and determine that the problem was in fact Microsoft
bug numbers Q296265 and Q293841. The details of Sybase Engineering's
findings are as follows...
What happens is the receiver issues a winsock receive (WSArecv) call
with the flag MSG_OOB to receive out of band data on the socket. When
this is the case, the receiver will receive any amount of data from the sending
end regardless of the setting of the receive buffer size. This pending data is
stored in non-paged pool until the application retrieves it. Without using the
MSG_OOB flag, winsock behaves properly, ie. when the receive buffer is full,
it blocks any further data being sent until the app performs another read to
empty the buffer. With MSG_OOB, this mechanism appears broken.
The reason this is only seen with bcp is the nature of the bcp program. Normal
ASE clients expect acknowledgements on a regular basis and will not continually
pump data across to the server without seeing them. BCP sends its data in a
continuous stream for maximum performance, utilising the standard TCP/IP flow
control.
According to the following Microsoft bug documentation, there is a fix available
for this problem in Windows 2000 Service Pack 3. Sybase Engineering has
downloaded and applied the patch to the server running their ASE and found
that it does indeed resolve the problem.
The Service Packs need to be applied to the server running ASE. The client
machines do not need the Service Pack applied.
If you are unable to apply the appropriate service packs, you can implement
one of the workarounds previously identified...
1) Change the packet size of bcp.
a) Use the "-A" command line parameter.
or
b) Create on "ocs.cfg" configuration file with the following entry:
[bcp]
CS_PACKETSIZE=4096
NOTE: Increasing the packet size has the added benefit of increasing bcp performance!!!!
There is a law of diminishing returns so setting it to 8192 might decrease performance.
This is documented in the ASE P&T Guide.
This change would require their ASE configuration parameters for "max packet size"
and "additional network memory" to be adjusted. However, only customers
experiencing the problem would need to implement this workaround.
2) Changing each client's sql.ini entry so that named pipes are used. This changes
the communication protocol so that Microsoft's Winsock layer is not used.
According to Microsoft documentation, customers must contact Microsoft for
a fix to Windows NT 4.0.
Q296265 - Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;q296265
Q293841 - Windows NT 4.0
http://support.microsoft.com/default.aspx?scid=kb;[LN];Q293841
Per the instructions above -
sp_configure reveals:
max network packet size = 4096
additional network memory = 4096
ocs.cfg contains:
[DEFAULT]
CS_PACKETSIZE=4096
[isql]
CS_PACKETSIZE=4096
and still the following occurs:
C:\>isql -Usa
Password:
CT-LIBRARY error:
ct_connect(): network packet layer: internal net library
error: Net-Lib protocol driver call to connect two endpoints failed
jisql connects fine. Embarcadero Rapid SQL connects fine. isql is
still having problems. What am I missing?
steve