Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase

Excel Source DT_NTEXT Problem Expand / Collapse
Posted Thursday, April 18, 2013 8:50 AM


Group: General Forum Members
Last Login: Tuesday, July 12, 2016 4:01 PM
Points: 11, Visits: 85
i am trying to load the data from excel files and facing problem in Text data.
Excel source in SSIS tries to pull data as STRING as the first few rows contain lesser text.
Is there a way to make it think that the data is of type Unicode TEXT stream?
Or can any one send me some other solution like using a script component to pull data from EXCEL.
i am stuck with this for last two days and need to finish it by today.
Please help me out of this?
Post #1443918
Posted Sunday, April 21, 2013 1:12 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, June 9, 2014 6:15 AM
Points: 79, Visits: 243
SSIS always treat the Excel Source data as unicode. This is a issue which is very common when you are reading from Excel file. You have to read the data and then convert it to type(string, unicode) you desire to use. There are a lot of articles on internet which address this issue. You can find out on or you can refer the below link.

SSIS: 3 Ways to resolve Unicode and non-unicode data type issue?

Vikash Kumar Singh ||
Post #1444816
Posted Sunday, April 21, 2013 10:47 PM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 7:32 PM
Points: 3,527, Visits: 3,062
When you read data from Excel using SSIS, the OLEDB provider reads the first few rows of the worksheet and tries to guess what the data type is for each column based on the contents of these rows. So, if in the those rows, it only sees data that would fit into a "STRING", then this is the data type it uses. If it happens that there is a cell with a lot of data in it, then the provider may guess that the data type should be "NTEXT". The same sort of logic applies for numeric fields and (I think) dates.

You can't change this behaviour but you can change the number of rows that the OLEDB provider reads in order to make that guess. This value is stored in the registry. Try searching the registry on your machine for "TypeGuessRows" - you will find at least 2 instances of it for Excel (in a key something like HKLM\Software\Microsoft\Office\15.0\Access Connectivity Engine\Engines\Excel). By default the value is 8 which means that the OLEDB Provider will search the first 8 rows of the spreadsheet and use the values in those rows when it tries to guess the data type. If you increase this value, it will use more rows to do its guess.

This may not work for you all the time - that really depends on the nature of the data you are importing and whether the data that truly represents your data type is in those rows, but it is the only way I know to influence the choice of data type.

This process occurs whenever the spreadsheet is opened by the OLEDB provider i.e. every time the SSIS package runs. You will need to make the same registry change wherever the package will be executing.

Post #1444850
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse