August 21, 2009 at 9:17 am
I get this error if i try to import a tab delimited flat file to a table in sql server.
The column "Column 2" cannot be processed because more than one code page (65001 and 1252) are specified for it.
I have set the "alwaysUseDefaultCodePage" property of the destination connection to True.
There is no such property for the flatfile source connection.
I have gotten around it by setting the codepage property of the OLEDB connection to 65001 but i dont know what this did or why it worked.
What does this error mean?
Is it a bug or is it serving a usefull purpose?
Why did my "workaround" work?
Thanks!
August 22, 2009 at 12:10 am
Hi Winston Smith !
As per my understanding, u have set the flat file connection manager configuration setting correctly. You need to specify the delimiter in the connection manager.
Pls let me know which tasks u r using to achieve this task?
August 22, 2009 at 4:58 am
madhukeshwark (8/22/2009)
Hi Winston Smith !As per my understanding, u have set the flat file connection manager configuration setting correctly. You need to specify the delimiter in the connection manager.
Pls let me know which tasks u r using to achieve this task?
Hi.
I think you misread my post. I didnt change anything for the flatfile connection as the flag was not present. what i changed was:
1. I have set the "alwaysUseDefaultCodePage" property of the destination OLEDB connection to True.
2. I have set the codepage property of the OLEDB connection to 65001
This allowed the package to work but I would really like to understand what a code page is, why this error presents its self so often, if its a bug and if not, what usefullness does it provide.
Regarding what im using, i simply have a flat file connection feeding to a OLEDB destination connection
May 12, 2010 at 1:32 pm
i had the same issue except i was conn to sql server.
i had to delete everything and rebuild it with my flat file code page to = 1252 and it worked.
May 17, 2010 at 4:18 am
Hi;
CODE PAGE BACKGROUND:-
I was working with one SSIS package and created a second package that would use some of the configured controls from the first package. By copying controls from the first package to the second package, I ended up with several controls using the page number from its source. So, when I attempted to debug the second package I received the following message:
The "column1" cannot be processed because more than one code page (1252 and 65001) are specified for it.
In short the first SSIS package had a page number of 1252 and the second SSIS package had a page number of 65001. So all of the controls copied from the first package retained their 1252 page number references.
SOLUTION 1:-
1. I edited the metadata code-behind by replacing all 1252 page number references with 65001.
2:- setting "AlwaysUseDefaultCodePage" property of oledb source as true.
Summary:-
While building SSIS packages graphically within VS 2005 design mode, a metadata code behind page is modified to reflect the graphical controls used within the designer. It is here within the metadata code-behind where controls reference their parent page with a page number. Each SSIS package has a code-behind with a default page number. Different SSIS packages should have different page numbers.
June 6, 2010 at 5:22 am
having same in the same SSIS package
I also would like to understand where is the phantom codepage for and why
June 28, 2010 at 11:44 pm
IMO, this is obvious and very annoying bug
which I reported
No, response whatsoever in 2 weeks
I guess from my previous experiences with ingenuous "conveniences" in MS products,
it will be closed "by design"
August 22, 2012 at 3:42 am
I faced this issue , and just delete the existing source file (.csv) connection and re-create it. it get fresh code page 1252.
August 22, 2012 at 3:44 am
I faced this issue , and just delete the existing source file (.csv) connection and re-create it. it get fresh code page 1252.:-)
January 22, 2013 at 5:59 am
I've just encountered this bug too.
What caused it was I edited a package by deleting the Excel source and replaced it with a .rpt flat file source... then all hell broke loose 😀
The only way I managed to fix it (after an hour or so of browsing between the source and target's trees and messing with the codepages) was to delete my Derived Column and OLE DB Destination.
I'm about to press run, wish me luck.
Michael Gilchrist
Database Specialist
There are 10 types of people in the world, those who understand binary and those that don't. 😀
April 2, 2013 at 1:01 pm
In your dataflow right click your OLE DB Destination and click properties.
In your Properties pane which might be on the right side.
Under Custom Properties there is an option called AlwaysUseDefaultCode to True.
Manually change your DefaultCodePage to the code that it says it can't convert. So in my scenario it said it couldn't do pages 65001 to 1295. I changed the DefaultCodePage 65001. From there your Destination will have a "Warning" on it but you should be able to execute the package now.
May 15, 2013 at 3:36 am
This is a really old post, but is still the highest hit when it comes to searching google for this issue so I'll try to explain.
A code page in SSIS corresponds to the specific character encoding used e.g. ASCII is code page 1252 and UTF-8 is code page 65001. SQL Server stores character data using "Collations" corresponding to different code pages. A character encoding is the method in which characters are stored as binary data.
If you are using an OLE DB Destination where the actual destination is a SQL Server instance then you may encounter this error for several reasons.
1. Your "source" text file is UTF-8 and your destination columns are VARCHAR/CHAR datatypes. Note that most UTF-8 (99.9%) files contain unicode data so you should use NVARCHAR/NCHAR datatypes for the destination columns.
2. Your "source" text file is ASCII (code page 1252) and your destination columns are VARCHAR/CHAR datatypes but have a collation that supports double byte characters e.g. Korean_Wansung_CI_AS (code page 949), (I'm not sure if any of the SQL Server VARCHAR collations actually use code page 65001 though). If you never specified the collation when creating the table then you should check to see what the databases default collation is. You can fix the issue by altering the collation of the columns in the destination table to something such as Latin1_General_CI_AS, but I would avoid this if you can't say for certain that there isn't and won't be any non-ASCII characters stored in the data.
Be careful changing code pages if you don't know what they stand for. If SSIS automatically uses a code page of 65001 then you should not change the code page to 1252 as this will cause a corruption of all unicode data in the file, you will know this has happened if you end up with text that looks a bit like this "ㄴㅇ리ã…호댜ã…".
I've experienced many frustrations with similar issues to this, so can only hope that this post might save someone else from a little bit of pain.
June 20, 2013 at 7:40 am
In the flat file connnection manager editor, set code page property to 1252(ANSI-LATIN 1).
As it changes some time to other setting and gives this error.
July 2, 2013 at 3:49 pm
Thanks much! this worked like a charm to me.....
November 20, 2013 at 11:26 am
The likely issue is that you have a source and target that are two different data types (ANSI and UTF8).
Perhaps you ran an SQL statement to dump data from a table directly to disk and it defaulted to the UTF8 format, whereas your SSIS job is trying to load it to ANSI.
Typically, I have to convert whatever flat file I'm using to ANSI (if small, open it in notepad and save it as ANSI) in order to get rid of this issue, but you may be able to get around it in SSIS.
Darn, should have read through to page 2 before posting. 😀
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply