SSIS SQL 2012 OLEDB Source defaults all Date columns to DT_WSTR

  • Hi,

    I have a data flow task that moves date from one SQL 2012 Database to another SQL 2012 database using an OLEDB source. I have a problem that all columns of type Date are being mapped to the DT_WSTR datatype in SSIS.

    I have found the following which is quite interesting. I have checked the default mapping in the MSSQLToSSIS10.xml file and the Date datatype is mapped to DT_DBDATE as I would expect.

    http://www.simple-talk.com/sql/ssis/working-with-ssis-data-types/

    Has anybody else encountered this or have any ideas?

    Regards

    Daniel

  • What if you change the datatype of the output column in the advanced editor? Does that work?

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • Hi,

    Using the advanced editor does work but I have quite few packages with this problem.

    I'm pretty sure the problem is related to the MSSQLToSSIS10.XML mapping file but nothing I seem to do affects the way SSIS maps the columns. I think I am missing something here.

    However I have found that changing the OLEDB provider for my source connections from 'Microsoft OLE DB Provider for SQL Server' to 'SQL Server Native Client 11.0' fixes the problems as SSIS maps the columns to the right data types.

    The problem is not fixed but the work arround isn't too bad.

    Thanks

    Daniel

  • Daniel Forrester 123 (12/13/2012)


    Hi,

    Using the advanced editor does work but I have quite few packages with this problem.

    I'm pretty sure the problem is related to the MSSQLToSSIS10.XML mapping file but nothing I seem to do affects the way SSIS maps the columns. I think I am missing something here.

    However I have found that changing the OLEDB provider for my source connections from 'Microsoft OLE DB Provider for SQL Server' to 'SQL Server Native Client 11.0' fixes the problems as SSIS maps the columns to the right data types.

    The problem is not fixed but the work arround isn't too bad.

    Thanks

    Daniel

    Ah yes, it is recommended to use the native client instead of the MS OLE DB provider for SQL Server. This is one of those reasons 🙂

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply