Source Type 200 in SQL Server Import and Export Wizard?

Question

I am trying to import data from one database in a server to a new table in a different server, using SQL Server import and Export Wizard. (SQL Server Management Studio 2012)

In the wizard, I checked "Write a query to specify the data to transfer", and the SQL statement returns data containing the following four columns:

+-----------------------------------------------------------------------------+
| ID(varchar(100))  |  Title(text)  |  Description(text)  |  IsActive(tinyint)|
+-----------------------------------------------------------------------------+

I want to change the types for the new table to

+----------------------------------------------------------------------------------------+
| ID(varchar(4))  |  Title(varchar(200))  |  Description(varchar(2000))  |  IsActive(bit)|
+----------------------------------------------------------------------------------------+

So, in the "Column Mappings" page(In the "Select Source Tables and Views" page, I clicked "Edit Mappings..."), I changed the Destination Type to the above types. Then, after clicking "Next", in the "Review Data Type Mapping" page, I get an error that says "Found 3 unknown column type conversion(s). You are only allowed to save the package"

The Data type mapping shows the following information:

icon    Source Column    Source Type    Destination Column    Destination Type    Convert
----------------------------------------------------------------------------------
error   ID               200            ID                    varchar
error   Title            200            Title                 varchar
error   Description      201            Description           varchar
warning IsActive         tinyint        IsActive              bit    

Even if I don't change the data type in the "Edit Mappings..." page, I get the same error.

I don't understand what "200" means in the context of a data type, and how can I import this data to a new table in a different server?

I appreciate any help.

Answer 1

With a bit of experimentation this error only seems to occur when you have a query as the source. The accepted answer did not work for me as copying to a flat file would result in the same error.

To solve this I put my query into a View then selected Copy From one or more Tables Or Views instead of Write a query....

I went through the wizard normally after that and my data went through with no error

Answer 2

Unfortunately this is a BUG. See (and vote up) links below:

--> SQL Server Import and Export Wizard Does Not Recognise Varchar and NVarchar

and

--> DTSWizard in SQL 2012 SP1 no longer recognizes nvarchar/varchar data types when source is a query

Answer 3

I bet that text columns aren't able to be inserted into varchar columns with the wizard. Depending on how big the table is, you could export the source to csv via the SSMS and then import it. That should work but if you have multiple tables to import you could add a linked server. Then you can just qualify the old table or the new table like this:

insert into [new_server].database.dbo.tablename
select * from old_table

I know SQL2000 is a pain for creating linked servers though which is what I'm guessing you are trying to export from since you have text columns.

Answer 4

A long-term solution (besides Microsoft fixing it) (or have they already?) is also a few links deep from the answers posted.

On the affected machine, there is an xml file that defines a code-to-value mapping for each transform type.
What is seen with the "200" & "201" causing a failure, is a missing mapping
....well, it shouldn't have come through as "200/201", but as it did, we wish it were mapped

It can be inserted manually, if you are willing to play with such configurations.

Here is where I got the answer, quite a ways down the page: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/97ff1f01-c02a-4c9a-b867-8eaecc464cfb/2012-sp1-no-longer-recognizes-common-data-types?forum=sqlintegrationservices

The mapping files are in C:\Program Files (x86)\Microsoft SQL Server\110\DTS\MappingFiles\
(or equivalent)

There is one for each type of source-to-destination transform.

For going between SQL Servers, look at ones such as
MSSQLToSSIS10.XML
MSSql9ToMSSql8.xml
MSSql10ToMSSql9.xml

Where you see

<!-- varchar -->
<dtm:DataTypeMapping >
    <dtm:SourceDataType>
        <dtm:DataTypeName>varchar</dtm:DataTypeName>
    </dtm:SourceDataType>
    <dtm:DestinationDataType>
        <dtm:CharacterStringType>
            <dtm:DataTypeName>DT_STR</dtm:DataTypeName>
            <dtm:UseSourceLength/>
        </dtm:CharacterStringType>
    </dtm:DestinationDataType>
</dtm:DataTypeMapping>

Add the "200" mapping to match such that you end up with

<!-- varchar -->
<dtm:DataTypeMapping >
    <dtm:SourceDataType>
        <dtm:DataTypeName>varchar</dtm:DataTypeName>
    </dtm:SourceDataType>
    <dtm:DestinationDataType>
        <dtm:CharacterStringType>
            <dtm:DataTypeName>DT_STR</dtm:DataTypeName>
            <dtm:UseSourceLength/>
        </dtm:CharacterStringType>
    </dtm:DestinationDataType>
</dtm:DataTypeMapping>
<dtm:DataTypeMapping >
    <dtm:SourceDataType>
        <dtm:DataTypeName>200</dtm:DataTypeName>
    </dtm:SourceDataType>
    <dtm:DestinationDataType>
        <dtm:CharacterStringType>
            <dtm:DataTypeName>DT_STR</dtm:DataTypeName>
            <dtm:UseSourceLength/>
        </dtm:CharacterStringType>
    </dtm:DestinationDataType>
</dtm:DataTypeMapping>  

Fix nvarchar and any others in the same way!

Answer 5

I was able to work around this by casting character fields as char(##) in the SQL and then changing the destination data types to varchar(##). The fields might need trimming before use, but the import works.

Answer 6

This is the bug and was just fixed in SQL SERVER 2012 SP2.

Answer 7

You really don't need to do any fiddling with config, views or whatever. Just save the SSIS package and execute it by double-clicking it in Explorer. This will launch the "Execute Package Utility (DTExecUI.exe in the ManagementStudio folder) which should run the package without error.

Answer 8

Fastest solution is to export the data to a new table in the same database (source) using the import/export wizard. Then export the data from the new table. Somehow the import/export wizard works his magic (not really) at the time it creates the new table. Thank you Jyoti for ending the pain it was to use the import/export wizard.