For performance reasons we have (successfully) used pooling in our apps and
services on almost one hundred installations, NT 4.0 to 2000 servers (SQL
7.0 - 8.0), NT 4.0 to XP workstations without a problem in any combination.

Now with 5.2 (2003) server a local client is unable to connect and crashes
within the SQLDriverConnect call (SQLConnect as well). Does not return at
all.

When the same runs on any other client (4.0, 2000, XP), everything is OK.

The problem comes and goes with SQL_ATTR_CONNECTION_POOLING

100% sure the bug is not in our code - the pure MS-supplied code as shown in
Q164221 crashes precisely the same way.

When SQLSetEnvAttr(...SQL_ATTR_CONNECTION_POOLING...) is not used, it's ok,
BUT:
To quit using benefits of pooling is a solution with severe impact on
performance.
Any hint?
TIA

Jaroslav Pivonka

mailto:jpivonka@centrum.cz

// Windows Server 2003, 2 in a cluster, SQL Server 2000 EE SP4 (8.00.2039)

[quoted text, click to view]

Negative. 2GB each server.
Moreover it seems to be an ODBC problem, not server.

[quoted text, click to view]

Hopefully the first is true and somebody will fix it soon.

So far we have put a switch outside, enabling us not to use pooling (default
is yes), into a couple of generic services running on the cluster so we can
leave all but two new systems as they were, and on the new installations
we'll keep waiting until a patch comes.

[quoted text, click to view]

Up to XP SP2 using MDAC 2.8 SP1 everything works fine.
The problem came with Windows 2003 Server SP1 having MDAC 2.8. SP2

[quoted text, click to view]

Please try to check it. I have proven that freshly installed systems
(nothing but Win2003 SP1 w MDAC 2.8 SP2, SQL 2000 EE (8.00.2039)) fail to run
locally even the sample code shown in Q164221 (MS only, not a line of ours).
Remote clients (pre-2003) are ok.

Thanks

Hi

I am assuming that your are not using AWE memory, as you should apply hotfix
2040 for SQL Server SP4
(http://support.microsoft.com/default.aspx?scid=kb;en-us;899761)

As to the connection pooling, check the versions of the ODBC drivers between
your various platforms. You will notice Windows 2003 has the most recent
one.
It may be a bug in the driver, or it may be that the feature is not working
anymore.

Do you have the same problem with Windows XP SP2 or Windows 2003 SP1?
If so, I would open a case with Microsoft Support Services.

Regards
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@epprecht.net

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

[quoted text, click to view]

We are seeing the same problem on Windows Server 2003, no AWE.

We are seeing the same problem: A crash in SQLConnectW on Windows 2003. We
have a tiny C test program I can post, Dr. Watson crash reports, and an ODBC
trace log.

The test program performs the following:

SQLSetEnvAttr(SQL_ATTR_CONNECTION_POOLING, ...
SQLAllocHandle(SQL_HANDLE_ENV, ...
SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, SQL_OV_ODBC3, ...
SQLAllocHandle(SQL_HANDLE_DBC, ...
SQLSetConnectAttr(hdbc, SQL_ATTR_AUTOCOMMIT, SQL_AUTOCOMMIT_OFF, ...
SQLDriverConnect(hdbc, 0, (SQLCHAR*)szConnect, SQL_NTS, 0, 0, 0,
SQL_DRIVER_NOPROMPT);

The stack gets corrupted, so it is difficult to tell if the crash is in the
driver or ODBC proper:

*----> Stack Back Trace <----*
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\ODBC32.dll -
*** WARNING: Unable to verify checksum for c:\eimutils\cnxntest.exe
*** ERROR: Module load completed but symbols could not be loaded for
c:\eimutils\cnxntest.exe
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\kernel32.dll -
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012f63c 001597ac 00159798 00000000 0012f640 0x75bb2aa8
0012f664 75bb4059 001597ac 00871348 0012f724 0x1597ac
0012f6c0 4bfa3531 00000000 00871348 0012f724 0x75bb4059
0012f6e0 4bfa3694 00871e48 00871348 0012f724 ODBC32!SQLConnectA+0x1813
0012f718 4bfa45a0 00871e48 00871e68 00120000 ODBC32!SQLConnectA+0x1976
0012f734 4bf82b04 00871e40 00000000 00000000 ODBC32!SQLConnectA+0x2882
0012fe74 4bfa1968 00871348 00000000 00871478 ODBC32!SQLSetEnvAttr+0x2e7b
0012feac 0040112a 00871348 00000000 004b0d81 ODBC32!SQLDriverConnect+0x125
0012ffc0 77e523cd 00000000 00000000 7ffde000 cnxntest+0x112a
0012fff0 00000000 004011c2 00000000 78746341
kernel32!IsProcessorFeaturePresent+0x9e