🚀 go-pugleaf

I am the SQL Server DBA at the University of Nebraska.  We have a difficult
situation right now implementing SQL Server access to Windows clients who
use Trumpet Winsock and tcp/ip for access.

Background:
We upgraded to NTS v. 3.5 and SQL Server v. 4.21a and ODBC v. 2.0.
We have written a customized application in VB using ODBC connectivity.
This application is successful using NetBIOS, Novell IPX and ODI, and
MS TCP/IP winsock.

Problem:
Many, many of our end-users use Trumpet winsock.  The UNO campuses has a site
license to distribute this software to all departments.  We have no success
using this software with our VB/ODBC application.

Trace Results:
We traced the problem using an Analyzer product and found the following
situation.

1)  Using Winsock -- ODBC-client apparently sends a request to the DB:
SELECT nValue FROM MSysConf WHERE Config = 101.

2)  The DB replies back:
Invalid object name 'MSysConf'..
OVER AND OVER AGAIN.....

Trace Results using MS TCP/IP:
1)  Using MS TCPIP -- ODBC-client sends a request to the DB:
SELECT nValue FROM MsysConf WHERE Config = 101.

2) The DB responds "Invalid object name 'MSysConf'"

3) The ODBC-client responds "sp_server_info 1"

4) Processing continues as normal.

Does anyone understand this?  Are there settings that can be changed on the
Trumpet Winsock software to fix this?

MS clearly indicates that they ONLY support MS TCP/IP, however, the beauty
of using MS SQL Server at our University is that we are able to simply
using the client's existing network protocol and not a) change and b) pay for
additional network software.

We could 'fix' this problem by migrating all users on each of the four
campuses to Microsoft WFWG and MS TCP/IP, but, as you might imagine -- that
is not realistic.  Besides that, the end-user community LOVE Trumpet Winsock
and have experienced no problem with the product using other TCP/IP access
methods.

Unresolved, this issue could significantly impair our efforts to improve
access to U-wide information at our University using low-cost solutions.
If anyone is able to assist us with this, it would most certainly be
greatly appreciated.

Thanks.

Amy Stephen (402) 472-7675
SQL Server DBA
University of Nebraska -- Computing Services Network