Test scripts for MSSQL modules

This text gives some information on the test suits for MSSQL::DBlib and MSSQL::Sqllib. The exact behaviour of the scripts may depend on your SQL Server version, your regional settings and a few more things. Thus you may see failures, where I don't. This text attempts to indicate what could happen.

Running the test scripts

If you have Perl 5.004 or Perl 5.005, including ActiveState Perl 5xx, the simplest way to run the test scripts is with MAKE test. If you only have ActiveState 3xx, you only have the option of running the files directly from the command line. With AS 3xx you must be standing in the in the directory where the test scripts reside, Dblib/t and Sqllib/t respectively.

Before you can run the scripts, you probably need to edit the files DBlib/t/sqllogin.pl and Sqllib/t/sqllogin.pl to specify username, password and server. As shipped, they will attempt to log in as sa with no password on the local server. Don't forget to delete sensitive information from the files, when you have completed testing!

All test scripts run in tempdb, and does only create temporary tables and procedures.

Tests for MSSQL::DBlib

Please notes that the two latter tests requires that MSSQL::Sqllib is present as well.

1_dblib.t tests basic DBlib functions: logging in, getting a result set, using a message handler, using RPC routines. Somewhat pessimistic in nature, it aborts on the first error that occurs.

If you run it directly from the command line, you will see one error message; this is natural as we are testing the error handler.

2_bcp.t and 3_text.t tests BCP routines and dbwritetext respectively. There are no known issues with these scripts. If you are considering using the bcp routines to bulk copy from a file, 2_bcp.t might give you some hints.

Tests for MSSQL::Sqllib

All these tests do of course require that MSSQL::DBlib is present, as MSSQL::Sqllib is an heir of MSSQL::DBlib.

1_resultsets.t tests the various row and result styles. There are no known issues with this script. If you are bewildered by resulting structure of the various combinations of row and result styles, you might get an idea by studying this script.

2_sptest.t tests sql_sp and sql_insert. The script also tests all SQL Server 6.5 datatypes. This script is sensitive to your configuration and may fail when testing date values if your regional settings are such that "Apr" is not understood as a month. The tests for real and decimal numbers may fail with rounding errors. I know for a fact that the tests with the money datatype for sql_insert fails with SQL Server 7 Beta 3 which fails to round numeric literals.

3_conversion_t is very sensitive to configuration. It should pass if your OEM charset is CP850 and your server charset is Latin-1. With other combinations, a couple of the tests are likely to fail. Of course, I ought to write the script so that it skipped the tests with other configurations. However, finding out which are the default charsets for server and client, is part of the test. But let me it put this way: if test 1 fails, and the remaining tests are not run at all, you have a configuration problem. Presumably Win32::Registry is missing, or does not behave in an expected way. Then again, if you don't plan to use character-set conversion, there is no reason to lose sleep anyway.

4_errors.t tests the error handling. There are no known issues with this script, save that it leaves a couple of files around in the sqllib/t directory.

5_uniqueid.t tests use of the SQL Server 7 datatype uniqueidentifier. This test is skipped if your server is running 6.5 or lower.


Last updated 99-01-29 22:49