MaxDB upgrade/heterogeneus system copy problem with unicode conversion

Question

Project goal:
upgrade a Content Server Version 7.3.0.35   32bit Non Unicode to
version 7.6.06.16   64bit Unicode
I found and followed note 962019
My plan (following the note): 
-create a clone of the original Content Server (vmware clone)
-as per note 962019 patched server 7.3.0.35 to 7.3.0.62 (> 7.3.0.57)
-created index
-on a fresh installed windows 2003 server 64bit i installed Content Server with build 7.6.06.16
-using loadercli from the target server (7.6.06.16) exported data
Now i was ready to start the import, as the note states:
"if the database parameter _UNICODE is set to the value NO and you want to start the target system with SAP MaxDB Version 7.6, you can use procedure described here for the import into a target system only with SAP MaxDB Version 7.6.05 build 11 or higher"
Having version 7.6.06.16 i was confident on such procedure, but my import stops immediatly with error:
D:\exportKpro>loadercli -d PRD -u SAPR3,SAP -b import.sql
Loader protocol: 'C:\Documents and Settings\administrator\My Documents
\sdb\loader\log\loader.log'
Loader packages: 'C:\Documents and Settings\administrator\My Documents
\sdb\loader\packages'
Error connecting user SAPR3 to database PRD on local host: -25005
User (SAPR3) logon to database PRD failed: SQL error -8046 = Conversion from UNI
CODE impossible: 7600 (error position: 1)
And now i'm stuck with no hints on how to proceed.
Thanks in advance.
Regards
Simone Zaffalon

Answer 1

Hello Simone,
as you're staying on Windows platform, there is no need for a heterogenous system copy.
All you've to do is to upgrade the 32-Bit installation to your target release (why not use MaxDB 7.7 right away?).
Once this is done, you can check whether the database catalog is still non-unicode (_UNICODE=FALSE).
If it is, there is a catalog migration procedure you can use to change this.
If the 32-Bit database is as you want it, take a full data backup.
Then uninstall the 32-Bit software, install the same version of MaxDB in the 64-Bit fashion.
Finally create the db instance by a restore of the backup.
After a load_systab your database is fully ready to go!
Just to stress this again: the _UNICODE parameter is not about your data!.
It's about the database catalog.
Having this parameter set to YES you can create e.g. tables named with Unicode characters.
The parameter does in no way affect your business data!
Since many customers ask why they should't use loadercli for a scenario like this:
a) It's only supported if you must use it, that is, you change the byte-order of the OS platform
b) it's way faster than export and import. We're talking about a few hours compared to days here!
c) It's much safer and controllable to use backup/restore and SDBUPD and move on step-by-step than exporting all data into a big file chunk and hoping that everything will be fine afterwards.
regards,
Lars