Very Computer

Server:  NT Server 4.0 (SP2), SQL Server 6.5 (SP2)
Client:  NT Workstation 4.0 (No SP), Client app in PB5 & iSQL/w

Clients can run 1-3 queries fine, then client apps die.
iSQL/w generates Dr. Watson.
PB5 app returns error message:

        Bad token from SQL Server: Datastream processing out of         synchronization.

We have looked at all configuration info and have been unable to find
problems.  All systems are using same NIC with same driver version and all
client apps have been functioning fine for about 6 months now.

Error messages just started appearing recently (within last 10 days).
Norton AV was installed about the time that error messages started
appearing.  We have since unistalled Norton AV, but the problems persist.

Any help on this would be greatly appreciated.

Regards,

Steve Kastl

Quote:

> Server:  NT Server 4.0 (SP2), SQL Server 6.5 (SP2)
> Client:  NT Workstation 4.0 (No SP), Client app in PB5 & iSQL/w

> Clients can run 1-3 queries fine, then client apps die.
> iSQL/w generates Dr. Watson.
> PB5 app returns error message:

>  Bad token from SQL Server: Datastream processing out of  synchronization.

1.  Have all the clients had their db-lib/obdc drivers updated to 6.5 SP2
level?  
2.  This problem happens far more often with the tcp-ip protocol, especially
with sockets.  Can you use named-pipes instead?  In any case a network trace
will probably be needed to see where the error is.

 Protech Computing Ltd (MS Solution Provider)
 Using Virtual Access 3.52 build 159c (32-bit) on NT 4.0 SP2

ISQL/W is a dblib application and I believe the PB has both dblib and ODBC
interfaces, so assuming that you go the dblib way check the following file
versions or later:

ntwdblib.dll 6.50.213 7/29/96
dbmssocn.dll 6.50.201
sqlsrv32.dll  2.65.0213 7/29/96

both on the 32 bit client and the server.  I don't think your using ODBC,
but if you are, and you are going tcp/ip sockets the dbmssocn.dll is being
used by sqlsrv32.dll

Also, this is indicative of a true network error, maybe a router.  Try the
NT tracert command and check the route that the client is taking for packet
loss, look for errors in the NT event log and the sql error log for
additional clues as to what is wrong.

Any network stop signs in the event log of the server are definately a
problem.

Also, Neil is right, try a different net lib, maybe pipes.

Quote:> Server:  NT Server 4.0 (SP2), SQL Server 6.5 (SP2)
> Client:  NT Workstation 4.0 (No SP), Client app in PB5 & iSQL/w

> Clients can run 1-3 queries fine, then client apps die.
> iSQL/w generates Dr. Watson.
> PB5 app returns error message:

>    Bad token from SQL Server: Datastream processing out of
synchronization.

> We have looked at all configuration info and have been unable to find
> problems.  All systems are using same NIC with same driver version and
all
> client apps have been functioning fine for about 6 months now.

> Error messages just started appearing recently (within last 10 days).
> Norton AV was installed about the time that error messages started
> appearing.  We have since unistalled Norton AV, but the problems persist.

> Any help on this would be greatly appreciated.

> Regards,

> Steve Kastl

In the interest of functionality (not my decision, mind you) SQL was moved
to an NT Server 3.51 (no SP) machine.  Things are running fine, but the new
machine only has 32 MB RAM and things are going slow.

I noticed this new feature in SP2 for NTS 4.0:

"Microsoft also added two new API calls to NT 4.0, using SP2 as a delivery
vehicle. These two calls, ReadFileScatter() and WriteFileGather(), let
programs pull in data from an uncached file and store it in a discontiguous
buffer, and vice versa. They also give disk I/O-intensive applications such
as SQL Server and Internet Information Server (IIS) a serious performance
boost because you can now move data from memory to disk in one pass."

I am beginning to wonder if this is the culprit, or at least a contributing
factor.

Still trying to figure out why.

Steve Kastl

Steve,

Replied to earlier e-mail.  New api's are NOT used by SQL Server - not till v7
anyway.

 Protech Computing Ltd (MS Solution Provider)
 Using Virtual Access 3.52 build 159c (32-bit) on NT 4.0 SP2