Truncation errors importing to SQL Server 2005 from Excel

Question

Long story short, I\'m taking a bunch of excel documents one by one, and importing them using the Import/Export wizard into a database in SQL Server 2005.

Here\'s on

Answer 1

Here's what worked for me.

This is due to a wonderful setting within Excel in your registry that tells it to only check the first 8 rows of data within your spreadsheet to determine the column size for the remainder of all the data. The fix for this is to modify your registry to set it from 8 to 0. When it’s set to 0 it will check the entire spreadsheet. This may cause some performance issues during the initial data import if the file is extremely large. Here is the the registry key to search for (there may be more than one that needs to be set):

TypeGuessRows

Answer 2

In SQL Server Import Wizard as soon as you get to the section where you need to specify the file you are using to import data click on the "Advanced" options. This will show you all the fields in your input file together with the field properties. The property you need to change is "DataType". It usually defaults to "string[DT_STR]". If you change it to "text stream[DT_TEXT]" you will increase the size of the field substantially and therefore will most likely avoid the truncation error.

Answer 3

The wizard uses a smaller value as the standard varchar size for Excel data than you got in the wizard in SQL Server 2000. As a result it often truncates data that you are trying to do a quick import to a staging table on. However, when you do the wizard, one screen will ask you if you want to edit mappings and you can fix the size of the fields there. Or you can usea create table stament first to create a work table with the sizes you want (nvarchar(max) is good if you are looking at the data for the first time and have no idea how big the fields will be) and then import into it. With Excel, I know I have also had issues with SQl Server using only a few rows to determine datatype and then the insert failing for records (say for something like partnumber) because it thought based on the first few records it was an integer when it was really a string type of data. You also could be having an issue like this, so it is a good idea to review the mappings anyway even if you don't get truncation errors.

Answer 4

http://support.microsoft.com/kb/281517

To change the value of TypeGuessRows, use these steps: 1.On the Start menu, click Run. In the Run dialog box, type Regedt32, and then click OK. 2.Open the following key in the Registry editor:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel

Note For 64-bit systems, the corresponding key is as follows:

HKLM\SOFTWARE\wow6432node\microsoft\jet\4.0\engines\excel 3.Double-click TypeGuessRows. 4.In the DWORD editor dialog box, click Decimal under Base. Type a value between 0 and 16, inclusive, for Value data. 5.Click OK, and then exit the Registry Editor. A second way to work around this problem (without modifying the registry) is to make sure that rows with fields, which have data 255 characters or greater, are present in the first 8 rows of the source data file.

Answer 5

For occasional imports of Excel, CSV or text data into SQL Server where truncation errors are being experienced, I would suggest importing the data into MS Access first and then using the up-sizing wizard to create and populate the table directly in SQL.

Answer 6

When I get truncation errors, I insert 8 dummy rows. Each cell has junk text with length > 256. This forces the detected data type to be varchar(max) instead of varchar(256). If a row is a number column, I have to fill it in with a number (for example, 0) and if it is a date, I have to fill in a dummy date or else the columns will import with null data.

I then delete these junk rows after the import.