SSIS Lookup transformation including whitespace

Question

For some reason, the SSIS Lookup transformation seems to be checking the cache for a NCHAR(128) value instead of a NVARCHAR(128) value. This results in a whole bunch of appended whitespace on the value being looked up and causes the lookup to fail to find a match.

On the Lookup transformation, I configured it to have No Cache so that it always goes to the database so I could trace with SQL Profiler and see what it was looking up. This is what it captured (notice the whitespace ending at the single quote on the second last line - requires horizontal scrolling):

exec sp_executesql N'
 select * 
 from (
  SELECT SurrogateKey, NaturalKey, SomeInt
  FROM Dim_SomeDimensionTable
 ) [refTable] 
 where [refTable].[NaturalKey] = @P1 
  and [refTable].[SomeInt] = @P2'
,N'@P1 nchar(128)
,@P2 smallint'
,N'VALUE                                                                                                                           '
,8

Here's the destination table's schema:

CREATE TABLE [dbo].[dim_SomeDimensionTable] (
[SurrogateKey] [int] IDENTITY(1,1) NOT NULL,
[NaturalKey] [nvarchar](128) NOT NULL,
[SomeInt] [smallint] NOT NULL
)

What I am trying to figure out is why SSIS is checking the NaturalKey value as NCHAR(128) and how I can get it to perform the lookup as NVARCHAR(128) without the whitespace.

Things I've tried:

• I have LTRIM() and RTRIM() on the SQL Server source query.
• Before the Lookup, I have used a Derived Column transformation to add a new column with the original value TRIM()'d (this trimmed column is the one I'm passing to the Lookup transformation).
• Before and after the Lookup, I multicasted the rows and sent them to a unicode Flat File Destination and there was no white space in either case.
• Before the lookup, I looked at the metadata on the data flow path and it shows the value as having data type DT_WSTR with length 128.

Any ideas would be greatly appreciated!

Answer 1

It doesn't make any difference.

You need to look elsewhere for the source of your problem (perhaps the column has a case sensitive collation for example).

Trailing white space is only significant to SQL Server in LIKE comparisons, not = comparisons as documented here.

SQL Server follows the ANSI/ISO SQL-92 specification (Section 8.2, , General rules #3) on how to compare strings with spaces. The ANSI standard requires padding for the character strings used in comparisons so that their lengths match before comparing them. The padding directly affects the semantics of WHERE and HAVING clause predicates and other Transact-SQL string comparisons. For example, Transact-SQL considers the strings 'abc' and 'abc ' to be equivalent for most comparison operations.

The only exception to this rule is the LIKE predicate...

You can also easily see this by running the below.

USE tempdb;

CREATE TABLE [dbo].[Dim_SomeDimensionTable] (
[SurrogateKey] [int] IDENTITY(1,1) NOT NULL,
[NaturalKey] [nvarchar](128) NOT NULL,
[SomeInt] [smallint] NOT NULL
)

INSERT INTO  [dbo].[Dim_SomeDimensionTable] VALUES ('VALUE',8)

exec sp_executesql N'
 select * 
 from (
  SELECT SurrogateKey, NaturalKey, SomeInt
  FROM Dim_SomeDimensionTable
 ) [refTable] 
 where [refTable].[NaturalKey] = @P1 
  and [refTable].[SomeInt] = @P2'
,N'@P1 nchar(128)
,@P2 smallint'
,N'VALUE                                                                                                                           '
,8

Which returns the single row