Because we had a code page issue with indexes, we change the code page of the database from UTF-8 to undefined and rebuild the indexes. The code page issue has been solved. But I wonder if there are negative side effects of a database with code page undefined.
If you had a code page issue I suspect that you have some non-ASCII data in the database, and one or more characters are not correctly encoded in utf-8. Setting the database code page to undefined does not solve the problem, it disables character conversions for data that is written to or read from the database.
If you have clients running with code pages other than utf-8 writing non-ASCII characters to the database, you already have more character corruptions that will be difficult to fix. Even if all clients are using utf-8, setting the database to code page undefined is highly undesirable.
I would urge you to contact technical support to help you correctly resolve the original data corruption issue and to reset your database to utf-8 as soon as possible.
> After rebuilding the indexes, the supplier get "index could not be deleted" error message.
I guess idxbuild also reported the errors for the unique indexes.
The "undefined" codepage means the sorting order is also "undefined". I mean that the sorting table (-cpcoll basic) is not defined for the "undefined" codepage. It's not changed when you change a codepage using proutil -C convchar convert.
If you had a code page issue I suspect that you have some non-ASCII data in the database, and one or more characters are not correctly encoded in utf-8. Setting the database code page to undefined does not solve the problem, it disables character conversions for data that is written to or read from the database.
If you have clients running with code pages other than utf-8 writing non-ASCII characters to the database, you already have more character corruptions that will be difficult to fix. Even if all clients are using utf-8, setting the database to code page undefined is highly undesirable.
I would urge you to contact technical support to help you correctly resolve the original data corruption issue and to reset your database to utf-8 as soon as possible.
Your right it doesn't solve the problem, but we don't get the error message "index could not be deleted".
The customer is moving the database to the "cloud". The databases on premise are running on Windows, but the "cloud" is Linux. So we have to dump and reload. After rebuilding the indexes, the supplier get "index could not be deleted" error message.
I know exactly what the problem is and I warn the supplier of the cloud (and customer) that this is not the solution of the problem.
The customer did (in the past) some unsupported stuff on the database which cause this problem.
> After rebuilding the indexes, the supplier get "index could not be deleted" error message.
I guess idxbuild also reported the errors for the unique indexes.
The "undefined" codepage means the sorting order is also "undefined". I mean that the sorting table (-cpcoll basic) is not defined for the "undefined" codepage. It's not changed when you change a codepage using proutil -C convchar convert.
No, the index rebuild was successful without errors. The error appeared when the record was updated.
>> The "undefined" codepage means the sorting order is also "undefined". I mean that the sorting table (-cpcoll basic) is >> not defined for the "undefined" codepage. It's not changed when you change a codepage using proutil -C convchar
>> convert.
Good to know!
No, the index rebuild was successful without errors. The error appeared when the record was updated.
>> The "undefined" codepage means the sorting order is also "undefined". I mean that the sorting table (-cpcoll basic) is >> not defined for the "undefined" codepage. It's not changed when you change a codepage using proutil -C convchar
>> convert.
Good to know!