Nope,

STEP 1

In the Variables for the package there is a variable that holds the string SELECT ID ,Description FROM MyTable WHERE LastUpdatedDate >= '[DateChanged]'

STEP 2

Then there is an execute SQL task that places a varchar(4000) column from a SQL table that holds all of the SQL statements to be used. The Execute SQL Statement puts the result set into the same variable.

STEP 3

Then there is a data flow task, the first part of this is an ole db source that executes SQL from command variable

So when in debug mode

AT STEP 1 before anything is executed you can see the default value for the variable and it is as expected i.e SELECT ID ,Description FROM MyTable WHERE LastUpdatedDate >= '[DateChanged]'

AFTER STEP 2 The contents of the variable change to become SELECT ID ,Description FROM MyTable WHERE LastUpdatedDate >= 01/03/2015

STEP 3 is where the fun begins. When run as SQL Agent job all is well. When run in bids if you open the OLE DB source then it complains that a date is being compared to a string. Now that only seems fair as anything in single quotes is a string so that seems fair does!

So how come it works in SQL Agent but not executed in BIDS on a 32 bit operating system?

Where the hell or where ever does the 012/03/2015 come from??

There is no variable within any scope in the package!

This is not being passed as a parameter from a parent package.

This is not in any execute DTUTIL command line I can see anywhere

I can not see it in package configuration

I did wonder if it had been declared as a variable at some point in an execute SQL task on the SQL Server and if the connection was retained etc.....

I can not see it as an environment variable.

This is why I think its an amazing puzzle.

E