Upgrade Error 10.0.13 to 11.0.6 - Installation Warning (Code Page 950 vs 1252 / Collation Mismatch)

Usage and Config
1

Hi everyone,

I am currently trying to upgrade our BigFix Platform from version 10.0.13 to 11.0.6. When I run the installation generator, it fails and throws this warning:

"The database appears to be in an inconsistent state. Please contact your support representative. Database Error: The code page of this application (950) does not match the code page of the database (1252)."

I did some digging and checked the SQL collation settings for our environment based on a KB article I found (KB0098763), and it looks like our databases are completely mismatched:

  • SQL Server Instance: Latin1_General_CI_AS

  • BFEnterprise & BESReporting: Chinese_Hong_Kong_Stroke_90_CI_AI

  • BFInventory: SQL_Latin1_General_CP1_CS_AS (I realize this is case-sensitive, which is definitely an issue).

The KB article says that for the BESAdmin tool and upgrade to work, the collation must be identical at the Server, Database, and Column levels, and it must be case-insensitive.

Since we don't have a dedicated DBA team on staff, I'm trying to figure out the safest way to standardize all of this to Latin1_General_CI_AS.

I found some scripts online suggesting I use ALTER DATABASE and then write a script to do ALTER COLUMN for every single text column in the database. However, I'm worried this might break constraints or indexes inside the BigFix schema.

Has anyone run into this specific upgrade block before? What is the best practice for getting the column-level collations matched up safely? Is it better to try the ALTER COLUMN scripts, or should we be looking at exporting the databases as a BACPAC, creating new databases with the right collation, and importing the data back?

Any advice or experiences would be greatly appreciated! Thanks in advance.

2

I’m not a SQL expert, but I have seen a similar error during BigFix upgrades/migrations, particularly after a SQL Server reboot. In my case, when I checked the SQL database, it was still in a recovery state.

Could you check the current state of your SQL databases? If the database is still recovering, I would suggest waiting for the recovery to complete and the database to return to an ONLINE state before continuing with the upgrade.

However, if the database is already ONLINE and you are still seeing the same error, then this may be a different issue. In that case, I would suggest involving your DBA team and raising a support case with HCL for further investigation.