Test scripts for Win32::SqlServer

This text gives some information on the test suite for Win32::SqlServer.

Requirements for Running the Scripts

Obviously you need SQL Server. It can be any version of SQL Server supported by Win32::SqlServer. There is no requirement that you have a certain edition; Express Edition will work just fine. (But note that Azure SQL Database will not, as the test scripts assumes that they can access tempdb, create databases etc.) Which tests that are performed depends on the SQL Server version: Generally, the higher the version, the more tests.

The test script assumes that you are running with the permissions needed in SQL Server. Several test scripts create databases and one creates a login and will fail if you don't have permission. Many scripts also create tables and executable objects in tempdb. You may not have be a member of sysadmin to run the scripts, but it's certainly the easiest way out. It goes without saying that you should not run the tests on a production server.

If a script terminates normally, it should drop everything it creates. (If not, that's a bug in the test script.) But if a script crashes, you may have to clean up manually. Below, I detail what each script creates.

Collations, Regional Settings etc

A challenge with writing these scripts is that they to some extent depends on settings for language, regional settings etc, both on the client computer running the tests and the SQL Server instance. I have mainly developed the tests under these conditions:

I have occasionally run the tests with different regional settings to ensure that DATETIME_REGIONAL works. I have one test instance with a Czech collation and antoher with Chinese collations, and on these instances I see failures related to varchar data. I have not tested with a different ANSI code page that those listed above – most likely you will see errors in this case, because the test may use characters not available in your code page. If you use non-English version of SQL Server and/or SQL Server client, tests where I test on text in error messages will fail. These shortcomings should not be construed as restrictions in what Win32::SqlServer supports, it is just the difficulty to cover all in a test script.

Running the Test Scripts

All test scripts looks at the environment variable OLLEDBTEST. This variable controls which server(s) the test scripts should access. OLLEDBTEST has this format:


If you don't specify Server1, the test script uses the default instance on the local machine. If you don't specify User1, the test scripts logs in with Windows authentication. Server2 is a second server, and is needed for some tests in the script 9_loginproperties.t. If you don't specify Server2, or it is the same as Server1, those tests are skipped. Example: to run the test at the server DEVSERVER with Windows authentication, and skip tests that require a second server, simply say:


To run the test on your local server and DEVSERVER as a second server, now with SQL authentication, you would say:

   SET OLLEDBTEST=.;;;DEVSERVER;sa;notstrong

The last option in the string is Provider. Use this if you want to force a certain provider. You will neeed to use this if you want to test against a version of SQL Server which is not supported by the default provider, which always is the most recently released proivder. The values for Provider are: 1 – SQLOLEDB, 2 – SQLNCLI, 3 – SQLNCLI10, 4 – SQLNCLI1, 5 – MSOLEDBSQL, 6 – MSOLEDBSQL19.

The simplest way to run the scripts is to run them with MAKE test.

A poor man's test harness is avilable in the t directory. Do:

   CD t
   set OLLEDBTEST=...
perl testitall.pl

This will run all the test scripts in order and analyse the output. Note that for this to work, you first need to have installed Win32::SqlServer in your Perl installation. (As you would if you are relying on the binary distribution.)

Reporting Errors from Tests

If you run a test script and one or more tests fail, please don't just tell me that test 324 in some script failed, put please send me the full output from the script. The test numbers are assigned dynamically in several of the scripts, so I may not be able to easily find which is test 324. I also need to know which version of SQL Server you are using and which provider.

The Test Scripts


Tests: the various row, result and colinfo styles.

Number of tests: 414.

Creates in SQL Server: Temporary tables only.


Tests: that Win32::SqlServer handle all SQL Server data types correctly. As a side effect it also tests sql_sp(), sql_insert() and that the log file is correctly constructed.

Number of tests: Between 2600 and 4200 depending on your SQL Server version, your OLE DB provider and things like whether the CLR is enabled.

Creates in SQL Server: Tables and stored procedures in tempdb, and on SQL 2005 and later also an XML schema collection and three CLR user-defined types (the latter only if CLR is enabled and CLR strict security is not in force).

Known issues: For OLE DB providers earlier than MSOLEDBSQL 18.5, five tests fail, unless you have a UTF8 collation, because of a bug in the OLE DB providers reated to NUL characters.


Tests: return values of different data types from stored procedures and user-defined functions for sql_sp().

Number of tests: 33-43 (SQL 2000 and SQL 2005), 79 (SQL 2008 and later).

Creates in SQL Server: stored procedures and user-defined function in tempdb, and on SQL 2005 and later also an XML schema collection and CLR user-defined types (if the CLR is enabled and CLR strict security is not in force).


Tests: the charset conversion you can set up with sql_set_conversion(). If your OEM code page is not CP850 or CP437, some of the tests are skipped. If the code page for your system collation is not 1252, the entire test is skipped.

Number of tests: 37. Some tests are skipped if the CLR is not enabled and CLR strict security is not in force. Tests for table-valued parameters are only performed if you have SQL 2008 and SQLNCLI10 or later.

Creates in SQL Server: CLR user-defined types and a table type, if these features are available. Else only temporary objects.


Tests: the error handling.

Number of tests: 237. Some tests are skipped depending on the SQL Server version.

Creates in SQL Server: On SQL 2008 and later the test creates a table type in tempdb. Else only temporary objects.


Tests: passing parameters to sql().

Number of tests: 113. With SQL 2005 and SQL 2000 a few tests are skipped. For all tests to be exected, you must have SQL 2008 or later, SQLNCLI10 or later and the CLR must be enabled and CLR strict security must not be in force.

Creates in SQL Server: User-defined types in tempdb. On SQL 2005 and later, it creates an XML schema collection in tempdb, as well as four CLR user-defined types if the CLR is enabled.


Tests: how Win32::SqlServer looks up the procedure and table names for sql_sp() and sql_insert(), as well as the names for user-defined types for sql() and also how it parses the "typeinfo" argument for the UDT and xml data types in SQL 2005.

Number of tests: From 1140 on SQL 2000 to 3641 (SQL 2008 or later with SQLNCLI10 or later). While the latter combination has the highest number of tests due to the available feature set, you will also need to run for SQL 2005 or SQLNCLI to test all apsects of user-defined data types. (Because for SQL 2008 and SQLNCLI10, the script tests user-defined types with table types only, but these types cannot be used across databases, which Win32::SqlServer supports for regular user-defined types.)

Creates in SQL Server: This script creates no less than five databases. Four of them have names starting in "OlleDB" or Olle$DB", and the fifth has all Greek letters, Ρεκσμοερνγως. The script also creates objects in these databases and adds guest as user.


Tests: the type information returned when the colinfo style is COLINFO_FULL.

Number of tests: 36, of which some are skipped depending on the SQL Server version, the OLE DB provider, the collation and the availability of the CLR.

Creates in SQL Server: Temp tables. On SQL 2005 and later, it creates an XML schema collection in tempdb, as well as four CLR user-defined types, if the CLR is enabled and CLR strict security is not in force.


Tests: setloginproperty() and other connection routines.

Notes: to perform all tests, this script requires that you have defined a second test server with the OLLEDBTEST environment variable.

Number of tests: 49, whereof three will be skipped if no second server is defined. Some tests are skipped depending on the version of SQL Server and the provider. Only with SQL 2005 or later and MSOLEDBSQL19 or later and a second server all tests will be performed. And even in that case, two tests will be skipped if SQL Server is configured for Windows authentication only. Four tests are skipped if you are testing against an instancs of LocalDB.

Creates in SQL Server: Creates a database which it detaches and then reattaches with a different name. Both names start with "OlleDB". On SQL 2005 and later, if SQL Server authentication is enabled, the script creates a login with the name starting in "Olle" followed by random digits. The script creates the login with CHECK_POLICY = OFF. As all other objects the test script creates, the login is dropped if the script terminates normally. No objects are created in the second server.

Known issues: I have seen the first two tests fail when integrated security is not possible. Instead of the expected login error, the connection attempt sometimes out. There is a test where I attempt to force the SQLOLEDB provider. This can fail if the server requires TLS 1.2 (I guess that is the reason). I've seen this when attempting to connect to a VM that runs CentOS 8.


Tests: table-valued parameters in general (some aspects of TVPs are tested in other scripts).

Notes: this test is skipped entirely unless you have SQL 2008 or later and the provider is SQLNCLI10 or later.

Number of tests: 1554 (somewhat fewer if the CLR is disabled or CLR strict security is in force).

Creates in SQL Server: various table types, a XML schema collection and four CLR UDTs if the CLR is available.


Tests: the OpenSqlFilestream method.

Notes: this test is skipped entirely, if any these are true: 1) The version is SQL 2005 or earlier. 2) Filestream is not enabled for remote access according to sys.configurations. 3) You run the test suite with SQL authentication. If the provider is SQLOLEDB or SQLNCLI, there is only a single test to verify that Win32::SqlServer croaks with the correct error message.

Note that the Filestream feature is configured in two places. In SQL Server with sp_configure and on Windows level through the SQL Server Configuration Manager. I have not been able to find out how to check for the latter reliably, so in case sys.configurations says that Filestream is enabled for remote access, but this is not the fact on Windows level, the test will fail big time.

Number of tests: 9.

Creates in SQL Server: the scripts creates a database, Olle$DB, with a FILESTREAM file group. It creates a table with filestream data in that database. The database is dropped at the end of the script.

Known issues: Some or most tests fail when connected to SQL 2008. I also see failures when testing against SQL 2008 R2, put sometimes all tests pass. No such issues are seen on SQL 2012 or later, save for the issue below.

On 32-bit Perl with USE_64_BIT_INT, the last test often fails for reasons I have not been able to understand. The test intends to pre-allocate a 80 TB record which is expected to fail, but the call unexpectedly succeeds.

WARNING! I have experienced Blue Screens with this test on one of my machines. Specifically it is the last test where I test to allocate too much that crashes Windows. The Blue Screen occurs on the machine where SQL Server is running and the error code is BAD POOL CALLER. I have not nailed the exact conditions for the crash to occur, but it seems to be a combination of filter drivers. The machine in question has an installation of Storagecraft's Shadowprotect which sets up a filter driver. There is also the fileinfo filter driver, which I am told is only comes with client O/S like Windows 10, but not server O/Ss.


Tests sending and retrieving char and varchar data with different collations.

Number of tests: 210 with SQL 2008 or later and the SQLNCLI10 provider or later. Fewer tests are executed with older versions of SQL Server and/or providers because of the lack of support for table parameters.

Creates in SQL Server: Three databases. Olle$DB0 (with the collation Latin1_General_CS_AS), Olle$DB1 (colation Greek_CS_AS) and Olle$DB2 (collation Czech_CS_AS in SQL 2017 or earlier. Czech_100_CS_AS_SC_UTF8 on SQL 2019 or later.)


Tests the properties CommandTimeout and QueryNotification.

Notes: This script runs for almost a minute, because of a 45-second WAITFOR to test CommandTimeout. That's why it is demoted to always be next-to-last in the test suite.

Number of tests: 11 (With SQLOLEDB), 9 (SQLNCLI or later providers and SQL 2000), 18 (SQLNCLI or later providers and SQL 2005 or later).

Creates in SQL Server: On SQL 2005 or later when you have SQLNCLI or later, the script creates a database, OlleQN, in which it creates a broker service service and a queue. In the other test cases, no objects are created.


Tests: Win32::SqlServer with Perl threads.

Number of tests: 24.

Creates in SQL Server: nothing.

Subdirectories to t

There are two subdirectories in the t directory:

Helpers - Here you find the source code for the four CLR types that are used in the test, and a Perl script to create them. Here is also a short program in VB6 which is used to generate and interpret date in regional settings for the DATETIME_REGIONAL setting. There is also test data for the spatial data types geometry and geography and the queries to generate that data.

Output - This directory holds output files from some of the test scripts. Most of them comes from 2_datatypes.t, and 5_errors.t, but also A_tableparam.t and Z_threads.t generate output files.

Last updated 22-06-09 22:59