We are replacing a development server and this has involved re-testing DTS packages on the new server.

We have hit an anomaly within a VB script within packages. Our script is called directly from a SQL job and, when we run this on the new server, it isbuilding a filename with a suffix of the current date in M/dd/YYYY format.This is behaving differently to our previous server which was using dd-MM-YYYY format.

This is causing failures. Rather than change any such scripts, I need to find and fix the date setting that is defining the default format. Our SQL support team state they do not think there is an issue with SQL Server 2000 default date.

Interestingly, if I run the DTS package in Design pakage mode, it picks up the default server setting for my ID (Uk date) and works correctly i.e. uses dd-MM-YYYY format. It is simply when run from the job that US date is used.

Are you running the package from some other server or your own machine(during design mode) when it executes successfully( ex: you connect from your own machine which has US timezone?)

On Tuesday, July 31, 2012 11:09:19 AM UTC+1, dashin... (AT) gmail (DOT) com wrote:
It was on the server itself.

However, this has now been solved. The machine default time was US and the userid used by the job was picking this up. The server default was changed and all is working now.