Сразу оговорюсь, что нормальное решение данной проблемы до сих пор не найдено.
Для начала предыстория. Клиент, достаточно крупный, УТ 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. И все ок:).
База на данный момент на проверке пользователей, но на первый взгляд все ок.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Как то не сходится текст статьи с конечным описанием решения. В тексте описано решение с переносом данных при помощи обработки ВыгрузкаЗагрузкаXML. В описании решения речь идет о замене таблицы Files в рабочей базе данными из пустой базы. И если первый способ понятен, то второй вызывает вопрос зачем таблицу с данными заменять на таблицу без данных?
(1) anchovy, гм, кажется, в статье все описано. Таблица FILES не хранит данные как таковые. То есть она не хранит данные конкретного справочника, документа и т.д. Как сказано в описании данной таблицы, она хранит так сказать техническую информацию, например, данные о хранилище конфигурации. Поэтому стало возможным заменить ее на не пустую, а соответствующую таблицу из пустой базы такой же конфигурации. Естественно, после всех этих плясок, необходимо провести физическое тестирование и тестирование исправление.
Так что решения в принципе два, только ВыгрузкаЗагрузкаXML не всегда корректно работает. Да и долго, если база большая.
Может быть я чего-то не понимаю….А нельзя ли было обойтись только заменой «косячной» таблицы без пункта ВыгрузкаЗагрузкаXML?
Как оказалось, можно было. Однако, не стал переделывать статью и убирать из нее второе решение, так как: первое, два решения лучше чем одно; второе, решение с заменой было найдено после написания статьи; третье, данный случай описан для таблицы FILES, возможно, для других основных таблиц(таблиц, хранящих техническую информацию) оно не подойдет, ради интереса, можно потренироваться и на других.
Методы научного тыка, одинэсина как всегда на высоте.
(4) iskan, Когда-то очень давно делали замену таблицы со структурой конфигурации. Но это было еще на 7.7…Попыхтеть пришлось. В каждом конкретном случае задачу приходится решать по-своему.
Пытаюсь создать и импортировать ранее выгруженную таблицу FILES (с другой базы с аналогичной конфой) следующим образом: указываю путь, жму «создание и импорт таблицы».Пишет, что таблица создана и импортирована, но при следующем открытии базы пишет, что таблица не найдена. В этой базе таблица была удалена tool_1cd кнопкой удаление текущей таблицы. В чем может быть проблема? Спасибо!
Прикрепленные файлы:
я решил так (на маленькой базе БП 3.0):
1. программно отключил использование итогов
2. распровел и провел проблемные документы
3. включил использование итогов
4 проверил что в ОСВ ничего не изменилось
А тупо пересоздать индекс на таблице Files никак не прокатило ?