The column "Column 2" cannot be processed because more than one code page (65001 and 1252) are specified for it.

  • 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!

  • 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?

  • 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

  • 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.

  • 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.

  • having same in the same SSIS package

    I also would like to understand where is the phantom codepage for and why

  • IMO, this is obvious and very annoying bug

    which I reported

    https://connect.microsoft.com/SQLServer/feedback/details/566945/bids-inserts-fanthom-code-page-s-into-ssis-2008-r2-components-irrelevant-to-format-locales-codepages-of-data-and-software-used-blocking-the-ssis-tasks

    No, response whatsoever in 2 weeks

    I guess from my previous experiences with ingenuous "conveniences" in MS products,

    it will be closed "by design"

    http://social.msdn.microsoft.com/Forums/en/sqlintegrationservices/thread/f6717d6d-3ffb-426f-8a82-96e1e3d131d8

  • I faced this issue , and just delete the existing source file (.csv) connection and re-create it. it get fresh code page 1252.

  • I faced this issue , and just delete the existing source file (.csv) connection and re-create it. it get fresh code page 1252.:-)

  • 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. 😀

  • 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.

  • 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.

  • 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.

  • Thanks much! this worked like a charm to me.....

  • 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