Пришлось обратить внимание к CHARACTER SET и COLLATION.
[QUOTE]
Алексей Шафранский написал:
База данных по умолчанию использует кодировку (character) utf8mb4 и коллейшен (collation) utf8mb4_0900_ai_ci.[/QUOTE]
В моём случае база данных, таблицы и колонки все были utf8mb3 и utf8mb3_unicode_ci
В Сети много публикаций, как поменять CHARACTER SET и COLLATION вроде [URL=https://confluence.atlassian.com/kb/how-to-fix-the-collation-and-character-set-of-a-mysql-database-manually-744326173.html]такой[/URL] и [URL=https://www.howtosop.com/how-to-convert-an-entire-database-from-utf8-to-utf8mb4/]такой[/URL], но я поступил проще. Временно закрыл доступ к сайту, временно удалил модули поиска и статистики (удалил с таблицами кроме той, что с шаблонами сообщений), сделал дамп базы данных в файл, поменял там utf8mb3_unicode_ci на utf8mb4_0900_ai_ci и utf8mb3 на utf8mb4, временно вырубил httpd и nginx, удалил базу данных, создал её снова, импортировал туда изменённый файл, и после запуска соответствующих демонов «Полное тестирование системы» перестало ругаться на ошибки в базе данных.
Кстати, «Полное тестирование системы» начало ругаться только после того, как я закомментировал в after_connect_d7.php следующий код:[CODE]$this->queryExecute("SET NAMES 'utf8'");
$this->queryExecute('SET collation_connection = "utf8_unicode_ci"');[/CODE]То же самое для порядка лучше сделать и в after_connect.php, хотя смысла уже в этом...
P. S. Кстати, как выяснилось позднее, после перехода на VMBitrix 9.0.0 у меня перестало работать резервное копирование, на самой начальной стадии — [I]после[/I] создания дампа базы данных (первые 15 секунд). Пока решения нет. Зато благодаря проблеме обратил внимание на разницу в CHARACTER SET и COLLATION.
