Make sure the SQL Server Browser service is running. It is required in order to listen for incoming connections. It may even be Disabled ( as in the case of SQL 2008 R2 Enterprise ).

I recently came across a problem while installing SQL Server 2005 with Windows Installer 3.1. I tried with Windows Installer 3.1 and v2 of 3.1. But it always kept failing. I resolved the problem by uninstalling Windows Installer 3.1 ( it will give a protest message that almost all the major services on my machine will fail, but just ignore it ). After uninstalling 3.1, I downloaded Windows Installer 3.0 and installed it. Rebooted my machine, and tried to install SQL Server 2005, and it succeeded !!!

There have been many reported problems with Windows Installer 3.1 failing silently in some cases. I for one, will be staying away from 3.1 till a proper next version is rolled out

Sometimes, when the excel column contains numeric and text data, and you try to import the excel data using say DTS, it will give you either the text values or the numeric values and return NULLs for the other. This is a known problem in excel as it scans rows ( based on the set count, which can be 1 ), and determines the datatype for that column. Any row which does not adhere to that guessed datatype, gets imported as NULL for that column.

A solution to this problem as shown by the knowledge base is to add the option IMEX=1; in the connection string. If you use something like DAO to open the excel data, then you can write as according to the MS knowledge article ID 194124 :


Set Db = OpenDatabase(“C:\Temp\Book1.xls”, _
            False, True, “Excel 8.0; HDR=NO; IMEX=1;”)


But the problem is that if we are using DTS, and the excel connection object is opening the connection. So there is no code present as shown above in the package. But fortunately, there is a place where we can modify it. In the excel connections properties ( visible either thru disconnected edit, or a dynamic property task or thru the API functions ), there is a key called OLE DB Properties -> Extended Properties. Add the setting IMEX=1; to the existing value and your problem should be solved. You will be able to import the entire excel sheet data thru DTS without worrying about missed values. This setting puts the mode of excel as import, and retreives all values as text instead of doing a data type guessing.

I was stuck at finding a solution to if a DTS Package is executing or not. It could have been started with the scheduler, or started manually. The only solution to this problem which I could come up with without any code changes to the package itself, was to enable Logging to SQL Server, and then checking the state of the package in the syspackagelog table by the following query


SELECT TOP 1 endtime FROM msdb.sysdtspackagelog WHERE
name = ‘Your Package Name’ ORDER BY starttime DESC


If it returns a date, then the package is not running, and if it returns NULL, then the package is currently in executing stage.

SQL Server 2000 DTS has a nice little Dynamic Properties task. But its usefulness for INI files is limited by some stupid limitations ( bugs/ features ) of the size of data in the INI files. To overcome it, the only possible solution I found was to write a custom ini file parser script and use it to directly retrieve values form the INI files. Fortunately I found a very nice script by Nolan Bagadiogn which uses regular exceptions and does not get limited in any way on number of spaces between keywords and values. Use this in an ActiveX Scripting Task, and enjoy

For reference, you can download it from
http://cwashington.netreach.net/depo/view.asp?Index=553&ScriptType=vbscript

Nolan, thanks for the nice script. It is very much appreciated.

If you would like to write custom error messages to the DTS log files thru your ActiveX scripts, the DTSPackageLog.WriteStringToLog method can be of help.

Just call it as

DTSPackageLog.WriteStringToLog “Custom Error Message”

and it will appear as a Task Log in the log file.

Very often there are cases when we want to have our DTS package to log error at a different path or file. This can very easily be achieved in the following way…

1. Read the log file path from a config file and store it to a global variable called ErrorLogFile using the Dynamic Properties Task.


2. Set the Package’s error log to the new value using ActiveX scripting.


set oPackage = DTSGlobalVariables.Parent
oPackage.Properties(“LogFileName”).Value = DTSGlobalVariables(“ErrorLogFile”).Value


While working on an assignment involving some complex data loading using DTS Packages, I came across the need to loop through all the files present in a directory and perform a set of tasks for each file and also handle errors on a per file basis.

I found this excellent article on sqldts.com which outlines a very simple yet effective way of condition based looping through dts tasks. Check it out here.