Search

DTSWizard in SQL 2012 SP1 no longer recognizes nvarchar/varchar data types when source is a query by K Dahl

Active

66
0
Sign in
 to vote
Type: Bug
ID: 772761
Opened: 11/29/2012 10:47:28 AM
Access Restriction: Public
3
Workaround(s)
25
User(s) can reproduce this bug
When using the import/export tasks from SQL Management Studio after SP1 has been applied, you can no longer use a query as a data source if it includes data types of varchar/nvarchar. These are no longer recognized from the SQL->SSIS data type mapping, and show up as 200 (varchar) and 202 (nvarchar). nchar also now maps to nvarchar, and binary maps to varbinary, when they previously mapped to their exact data types prior to SP1 being applied.
Details (expand)

Product Language

English

Version

SQL Server 2012 - Developer Edition

Category

Integration Services (DTS)

Operating System

Windows 7 Enterprise (SP1)

Operating System Language

US English

Steps to Reproduce

Steps to reproduce are included, along with screenshots, in the MSDN post here:

http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/97ff1f01-c02a-4c9a-b867-8eaecc464cfb

Actual Results

An error saying that the package can only be saved.

Expected Results

To go through to the next step and transfer the data.

Platform

X64

Virtualization

 
File Attachments
0 attachments
Sign in to post a comment.
Posted by SQLNoobie on 4/16/2013 at 12:57 PM
I have the exact same issue. I had been working with SQL Server 2012 Express edition and exported to csv was working just fine, once I installed SP1 via Windows Update a few days ago, I can no longer export due to the error "Source data type "200" was not found in data type mapping file" for any columns with a varchar type.

My workaround is to click the "Edit Mappings..." button on the "Configure Flat File Destination" page, then change the Type to "string [DT_STR]" from the incorrect Type "byte stream [DT_BYTES]" for each of the affected columns. This is such an inconvenience to have to do every time I export!
Posted by Uncle Cheese on 4/12/2013 at 3:39 PM
I am just reiterating John Soloman's point below. I export data every day from ad hoc queries - can I create views for them? Sure. It is absurd that I should need to do so. This should have been fixed months ago.
Posted by John Soloman on 4/12/2013 at 6:14 AM
That this issue still exists is beyond ridiculous. I'm wasting time every day to work around it.
Posted by The Gabe on 4/1/2013 at 9:43 AM
Has anyone received any feedback from Microsoft? I can not find where they have even acknowledged the problem exists. We have been wanting to switch over but with every SP1 and the 3 CUs more stuff has broken.

It sounds like Quality Control and Testing from Microsoft has tanked.
Posted by mbourgon on 3/14/2013 at 3:14 PM
Got this after installing SSMS from the ISO for 2012 with SP1.
Posted by jorgeghr on 3/14/2013 at 10:46 AM
I am experiencing the same issue. The suggested workaround is not a solution for me.
Posted by allmhuran on 3/3/2013 at 3:57 PM
Gotta watch out for those sneaky arcane and rarely seen data types like varchar...

Confirmed still broken in SP1. Creating a view works but is not really a workaround. If I didn't need parameters it would have been a view, but I do need parameters, that's why it's a function...
Posted by swh1 on 1/15/2013 at 1:26 AM
We have experienced the same issue. Fortunately, we have only got this installation to test so we have reinstalled 2012 without SP1 to allow us to continue without having to create unnecessary views.
Posted by trepur on 1/14/2013 at 5:14 AM
Evidently a problem with SP1 - uninstalling 2012 and re-installing without applying SP1 works
Posted by K Dahl on 12/11/2012 at 2:22 PM
You can also likely just save the package and go and edit it in DataTools, as the problem doesn't seem to occur there. Or just build the package in DataTools in the first place. However, that seems to defeat the lightweight intention of the DTSWizard.
Posted by Nirav Patel SQ on 12/7/2012 at 9:44 AM
Quick workaround to this is to create a view for query and it works
Posted by Nirav Patel SQ on 12/7/2012 at 9:42 AM
Same issue here. Only when query as a source. works fine with tables. also it does recognizes int, numeric data types but issue with varchar, char data types.
Sign in to post a workaround.
Posted by James Parker on 5/20/2013 at 8:44 AM
Same problem. However exporting to a CSV file works.
Posted by mbourgon on 4/18/2013 at 1:39 PM
Naves showed a partial workaround in this thread:
http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/97ff1f01-c02a-4c9a-b867-8eaecc464cfb/
Posted by digitallnet on 12/10/2012 at 8:01 AM
The workaround specified by Nirav Patel SQ worked for me - create a view of the data needed for exporting and then the mappings are successful and you can export.
© 2013 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement