В файловой БП3 версии 8.3.83.37 chdbfl выдает ошибку:
" Обнаружены дублирующиеся ключи в уникальных индексах таблицы '_USERSWORKHISTORY' "
и ничего, не исправляя внизу:
" Обнаружены нарушения ограничений уникальности индексов. Продолжать работать можно. "
Запускаю тестирование и исправление с исправлением со всеми галочками, но оно проходит, перерегистрирует объекты и никаких сообщений об ошибках.
А chdbfl снова выдает ту же ошибку.
Как ее исправить? Иногда у пользователей база внезапно закрывается.
(1)Произвести ТИ ( тестирование и исправление базы данных)
еще как вариант загрузить в SQL и DBCC CHECKTABLE (_UsersWorkHistory, repair_allow_data_loss)
(5)_UsersWorkHistory - таблица истории работы пользователя.
DBCC CHECKTABLE Производит проверку целостности всех страниц и структур, составляющих таблицу или индексированное представление.
REPAIR_ALLOW_DATA_LOSS
Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
"Если необходимо использовать аргумент REPAIR, выполните инструкцию DBCC CHECKTABLE без параметра восстановления, чтобы узнать требуемый уровень восстановления. При использовании уровня REPAIR_ALLOW_DATA_LOSS рекомендуется создать резервную копию базы данных перед выполнением инструкции DBCC CHECKTABLE с этим параметром."
Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
Частичная потеря данных может привести к более серьезным ошибкам?
Насколько я понимаю из названия таблицы, это просто история работы пользователей.
Если какой-то шаг работы пользователя сотрется - это же ни на что не влияет.
Но важно знать, что за пользователь был, возможно, у него связь с базой плохая или он оставляет базу открытой на неск.дней. Надо выявлять и вразумлять таких пользователей.
Так что мне интересна более полная информация об ошибке.
"Если необходимо использовать аргумент REPAIR, выполните инструкцию DBCC CHECKTABLE без параметра восстановления, чтобы узнать требуемый уровень восстановления. При использовании уровня REPAIR_ALLOW_DATA_LOSS рекомендуется создать резервную копию базы данных перед выполнением инструкции DBCC CHECKTABLE с этим параметром."
"Как ее исправить? Иногда у пользователей база внезапно закрывается."
Вы задали вопрос как исправить :) "DBCC CHECKTABLE (_UsersWorkHistory, repair_allow_data_loss)".
Хотите заняться более глубоким анализом?
История работы пользователей
Таблица _UsersWorkHistory
_ID - Уникальный идентификатор пользователя информационной базы
_UserID - ID пользователя - владельца настройки
_URL - URL
_Date - Дата время
_URLHash - Хеш по URL
Ошибка на уникальность индексов данной таблицы возникала при попытке загрузки dt в SQL. Вылечилось загрузкой в файловую и правкой таблиц через ToolCD 1C.
(12) Если конвертация базы в более ранний формат для того чтобы использовать tollCD не катит,
то можно воспользоваться инструментом "Библиотека 1CDLib (с) andrewks"
https://infostart.ru/public/166557/
На текущий момент реализованы следующие
Возможности:
- получение массива таблиц БД;
- сохранение данных таблиц в файлы ("сырые" данные!);
- загрузка данных таблиц из файлов ("сырые" данные!);
- переименование таблиц, установка им новых описаний;
- создание, удаление таблиц;
- получение массива полей таблицы, подсчёт длины одной записи;
- навигация по записям таблицы, чтение/запись полей и BLOB-полей;
- сохранение/загрузка BLOB-полей в файл;
- добавление, удаление записей;
- получение примитивной информации по метаданным;
- поддержка разных целевых платформ - Windows32/64, Linux64.
Также возможна работа с базой данных (и, также, с произвольными двоичными файлами блочной структуры) на "низком" уровне: реализованы методы по чтению/записи числовых и строковых данных из блоков файла.
Я с такой столкнулась ошибкой. Еще и на базовой версии бухгалтерии.
помогло так.(кончный релиз 3.0.150.33)
0. копия базы
1. тестирование файла с помощью chdbf
2. тестирование полностью в конфигураторе
потом все равно была ошибка в режиме предприятия при открытии.
3. открыла базовую в конфигураторе, открыла для редактиования (у меня еще ПРОФ базы есть и ключ, поэтому дало отредактировать). Открыла конфигурацию для изменения и сохранила.
4. загрузила .cf файл базовой конфигурации на 1-2 релиза старше.
5. получила базовую конфигурацию нового релиза, приняла изменения, запустила режим предприятия, ошибка исчезла, обновление прошло. Конфигурация осталась базовой.
Ошибка ушла.
Но на другой Проф версии так не прошло, там была конфигурация Бух Сельхоз Предприятия.
Там пришлось восстановить с архива на несколько дней назад.