I’m running into a small issue with our platform upgrade to TRIRIGA 3.5.1. One of the prerequisites of our 3.5.1 upgrade was to delete any custom tables from the database, because they interfere with the MBCS conversion process. We had a custom table that we are using for integrations, so we scripted it out and deleted it before starting the installation of 3.5.1. But for some reason, TRIRIGA still thinks that the table is there, tries to perform MBCS conversion on it, and throws an Invalid Object Name exception since the table does not really exist in the database.
I am not sure why the MBCS conversion process is looking for a table that does not exist. I am thinking that there’s a list of tables maintained somewhere in TRIRIGA and that’s what’s causing this issue. I’m hoping that someone else has seen this issue before and can guide me in the right direction.
I finally figured it out. I found the script that’s used for converting varchar to nvarchar, and one of the things it does is that it creates a table called IBS_MBCS_CONVERSION_RECOVERY, which is used in case the conversion of a table fails. It turns out that we still had an entry in IBS_MBCS_CONVERSION_RECOVERY for our custom table from before, which was essentially causing the platform to attempt a conversion every time on startup. Once I deleted the entry for our custom table, the conversion error went away.