Hello Christian, >But I remembered that our SAP systems made this step (convert >the catalog >from ASCII to Unicode). And then I found the (rather >undocumented) function >db_migratecatalog, which has to be executed in OFFLINE state. >It finished >its work and voila: _UNICODE YES. >
db_migratecatalog is not foolproof and should therefore only be used if you are certain that you don't run into any of its restrictions. During its run, views, triggers and db procedures (among others) will be recreated by parsing their statements, but not necessarily in the order they were created. This can fail if you have dependencies between those objects, resulting in a database with missing objects. If you migrate using db_migratecatalog you should always check the system table POSTUPGRADECHECKLIST_UNICODE once the migration has completed. There, all objects are logged that could not be recreated from scratch. You will usually find a lot of system views in there, but those don't matter because they get recreated during load_systab. For all other objects you should carefully check whether you need to recreate them manually (you should find the original statement string along with the error number in POSTUPGRADECHECKLIST_UNICODE). The only safe and recommended way to go from an ASCII to a unicode database is by using the loader. Best wishes, Martin. -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
