Сразу оговорюсь, что нормальное решение данной проблемы до сих пор не найдено.
Для начала предыстория. Клиент, достаточно крупный, УТ 10.3, файловая, конфигурация сильно переписанная (неведомыми деятелями до нас), пользователей много, отсюда сильное торможение базы. Предложили переход на SQL.
Клиент согласился, и мы недолго думая, продали соответствующие ПП. Наши программисты все установили, начали загрузку базы и тут возникла проблема: попытка вставки неуникального значения в уникальный индекс. Данная проблема достаточно распространена, и нас это не сильно испугало, благо мозгов и средств решения это ситуации вроде бы хватает.
А дальше началась канитель. Неуникальные индексы (числом 2) обнаружились в таблице Files, про которую немного написано в инете, в основном то, что в ней хранятся файлы, например, данные о хранилище конфигурации. Напомню, что хотя попытка вставки неуникального значения возникает у многих, в всемирной сети данный вопрос обсуждался и обсуждается, и есть много решений данной проблемы, но наша ситуация отличается от ситуаций описанных в интернете.
У всех прочих проблем одно общее свойство: неуникальные индексы возникали в таблицах вроде справочники, документы, регистры бухгалтерии и т.д. И это позволяло разными способами достаточно просто решить эту неприятность. Но у нас неуникальные индексы были в одной из основных таблиц базы Files, которую и не пощупать-то никак.
Были перепробованы все варианты исправления (про стандартные даже не говорю, тестирование и исправление даже не ругалось на это место), некоторые из нас дошли даже до того, что нашли в HEX данное место и заполнили его другими значениями. Единственное, что мы нашли через классную утилиту 1С Tools, это то, что один из индексов был создан в 11 году, второй 19.06.13. Дата создания второго индекса натолкнула нас на то, что данный индекс возник, возможно, при обновлении (22 релиз 10.3 был выпущен 10.06, а дата создания индекса 19.06.).
Единственное решение данной проблемы мы нашли такое: загрузить пустой DT с данной конфигурацией в SQL, а затем воспользоваться замечательной обработкой ВыгрузкаЗагрузкаXML. Перенос занял 2 суток, перенеслось все, кроме пользователей, клиенты до сих пор проверяют тестовые перенесенные данные. После их проверки, попробуем изменить конфигурацию и посмотрим, успешно ли будет обновить конфигурацию базы данных.
Вот такая история, продаешь клиенту SQL и сервер 1с на достаточно крупную сумму, а потом попадаешь в такую глупую ситуацию. Век живи, век учись.
Проблема решена!!!! Спасибо замечательной Tool_1CD (альфа версия с возможностью редактирования).
Описание решения:
1. Создаем пустой dt с нашей конфигурацией.
2. Загружаем в SQL(для проверки).
3. Выгружаем из SQL в dt.
4. Загружаем в файловую версию.
5. Просматриваем с помощью Tool_1CD нашу пустую базу, экспортируем таблицу Files.
6. Просматриваем с помощью Tool_1CD нашу родную базу(с двумя одинаковыми индексами), удаляем таблицу Files.
7. Указываем каталогом импорта путь к каталогу из пункта 5, нажимаем импортировать и создать таблицу.
8. И все ок:).
База на данный момент на проверке пользователей, но на первый взгляд все ок.
