We are planning to upgrade LN FP2 to LN 10.7 Unicode.
We interface with an LN ERP system that is changing to NVARCHAR2 text fields in LN 10.7 Unicode system. There are many applications that retrieve data from the Infor LN ERP system and join to a custom database. There are so many applications and SQL to change it does not seem feasible to rewrite all the code. Or should we consider converting all our custom applications to use NVARCHAR2 fields? Is there a risk doing mass conversions from VARCHAR2 to NVARCHAR2?
Unfortunately, Infor ERP LN made drastic changes to the database model. They changed the character set to UNICODE, but they did so at the field level, NOT database level. In addition, for all text fields they created function-based indexes on pseudo columns that are wrapped in the following function: NLSSORT("T$CADR",'nls_sort=''UCA0700_DUCET_S3_VN_BN_NY_EN_FN_HN_DN_MN''')
I am concerned that our SQL will no longer work with this new configuration and at a minimum we are headed for some big performance problems
- How your systems access LN data when you need it for other applications in you environment?
- How did you migrate your custom code to handle nvarchar2 unicode datatypes?
- When to use new functions that are character set specific such as
- LIKE VS LIKEC, LIKE2, LIKE4
- SUBSTR VS SUBSTRB, SUBSTRC, SUBSTR2, SUBSTR4
- LENGTH VS LENGTHB, LENGTHC, LENGTH2, LENGTH4
- INSTR vs INSTRB, INSTRC, INSTR2, INSTR4
Please advice!
