With InforCRM version 8.4, Infor has added the requirement that the database must utilize unicode datatypes. When upgrading to 8.4, Infor provides a utility called CreateUnicodeDB, which basically goes through the SQL objects of the database (tables, views, SPs, Functions, Schemas, etc…) and creates a copy of the database, replacing any non-unicode columns with their unicode equivalent; finally moving data from the original database, to the new, unicode enabled database.
I recently bumped into an issue with the order in which the utility creates database objects. SQL Users and schemas are processed first, followed by SQL tables, followed by the other SQL objects. In this particular database, there were scalar UDFs being used to create computed columns in a number of the SQL tables. Since the utility creates Tables before UDFs, it would error out on any table referencing that non-existent UDF, and subsequently any views or stored procedures created from that table. In addition, it also creates views before UDFs, so if a view is referencing a function, same issue.
I wouldn’t really classify this as a bug, since you can’t create the functions before the tables (in case the functions also reference a table), however some more robust error handling might be nice in this situation.
My solution for this particular case was to identify any tables containing a computed column referencing that UDF, then running an alter statement to drop those columns, as well as removing any view referencing a UDF. Then I run the CreateUnicodeDB utility to create the new database. Finally, I run another set of alter statements on the unicode database, adding those columns back in and creating the views.
Not a difficult work-around, but it can be a bit annoying if a database has a lot of computed columns.