In my company all tables are configured to use codepage 243 (= EBCDIC German). Cp243 however doesn't support the euro-sign "€". This causes a problem in one particular table, where the users enter freetexts. Cp1141 was developed out of Cp243 to support the euro-sign. Both codepages are nearly identical. According to our DB2 expert there could be performance problems or that "strange" issues may occur, if we migrate only that particular table to Cp1141 and join it with other tables that are still using Cp243. Is it indeed an all or nothing issue? I really don't feel like changing numerous tables.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
joining tables with different code pages 1
- Thread starter tom62
- Start date
Suggest you look at every byte in both CPages and make sure only the one value is different. And which value wil be forfieted if the Euro sign is included.
If the problem value is only entered in freetext, it would not participate in a JOIN would it?
If the problem value is only entered in freetext, it would not participate in a JOIN would it?
-
1
- #3
fredericofonseca
IS-IT--Management
you can use different encoding within joins.
but performance will most likely be affected. I strongly advise that you test this in advance by creating one copy of the table in question with the desired CP, and then testing performance with production size data and using the normal queries used by your current prod environment.
Look not only at timing but at performance analysis, query plans and so on. use Insight or similar if you can.
On top of this and before you consider the change you need to go through all your JCL's and applications that connect to this table, either directly or through extracts and see what is the impact of changing it, both in terms of work to eventually change the software to deal with a difference cp on this table and in terms of functionality - some of the software that consumes the data on this table may already be applying some internal conversion to deal with the fact that a particular hex value corresponds to the euro symbol.
The work above is the same you would have to convert ALL tables to the Euro codepage. Extra work if you would do the full conversion would be to change DB default and to unload/load the data back to DB
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
but performance will most likely be affected. I strongly advise that you test this in advance by creating one copy of the table in question with the desired CP, and then testing performance with production size data and using the normal queries used by your current prod environment.
Look not only at timing but at performance analysis, query plans and so on. use Insight or similar if you can.
On top of this and before you consider the change you need to go through all your JCL's and applications that connect to this table, either directly or through extracts and see what is the impact of changing it, both in terms of work to eventually change the software to deal with a difference cp on this table and in terms of functionality - some of the software that consumes the data on this table may already be applying some internal conversion to deal with the fact that a particular hex value corresponds to the euro symbol.
The work above is the same you would have to convert ALL tables to the Euro codepage. Extra work if you would do the full conversion would be to change DB default and to unload/load the data back to DB
Regards
Frederico Fonseca
SysSoft Integrated Ltd
FAQ219-2884
FAQ181-2886
- Thread starter
- #4
Thanks for the info. Basically it would be better to convert all tables, because the table that causes us problems is part of our purchasing and fact-sheet systems. Our sales, after-sales, calculation, marketing and some external systems all depend on it. For the moment I'll suggest a workaround solution (replace € by EUR) to the problem, until we find a sponsor for the CP conversion. We might then as well go ahead with Unicode, since we get more and more foreign clients that enter data that is not EBCDIC compliant.
Regards,
Tom van Breukelen
Regards,
Tom van Breukelen
- Status