Конфигурация КАМИН, ДБФ. Требуется перевести на SQL. Общий размер базы около 4ГБ. Максимальный размер таблицы 1.7ГБ.
Создал базу на SQL. Из базы 1с, через Администрирование, делаю выгрузку данных. Т.к. база большая, то предварительно ставлю плагин Unload_Data_Fix.
Создаю пустую базу 1с, настраиваю подключение к SQL, через Администрирование загружаю мои данные. После того, как загружено 100 процентов данных, выходит сообщение: "Create unique index terminated because a duplicate key was found for index ID 2." Оно же возникает при попытке открыть базу.
При загрузке данного файла в пустую ДБФ базу - проблем не возникает...

Кто знает в чем проблема? Как исправить?

где то задвоились записи

Согласне.. Как их можно найти? Запустил несколько скриптов на базе по поиску дублей. Ничего не найдено. Почему при загрузке в ДБФ такая ошибка не возникает?

(2) имя таблицы в сообщении не присутствует?

(2) посмотреь, какую таблицу индексирует, посмотреть выражение второго индекса, и найти запросом дубли

хотя бы имя проблемной таблицы для начала узнать

дублей может и не быть в таблице. дубли могут получаться в процессе наполнения таблицы. скорее всего это что-то типа таблицы подчиненных. искать нужно в профайлере на чем спотыкается и разбираться в причинах.

База слишком мелкая для перевода на скуль..
ЗЫ: И при всей базе в 4 гига из которых 1 файлик 1.7 - это явно что-то в консерватории менять надо, регистр этот например закрыть

(7) переводят не только из-за величины..

(7) а если это таблца проводок?:)

Нет регистров. На счетах все.. Индексы сыпаться начали. По-этому решили на SQL переводить. Для ДБФ предел размера таблицы - 2ГБ.

(10) да не вопрос, табличка поди - файло итогов по счетам ?
Имя этого файлика какое ?

Табличка содержит строки неограниченной длинны. Есть общий реквизит документов "Данные", тип: строка неограниченной длинны. В него записываются ВСЕ вычисления документов.
Имя файла: 1sblob.dbf.

(12) :))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

Имя таблицы, в которой задвоились строки, неизвестно. В сообщении не указано.

И.. что там за "вычисления" в этом реквизите ?

Ёпрст4 - ты над топик стартером не смейся. Это в самой конфе так все задумано. Специфическая система хранения данных.

(0) Вроде есть какая-то особенность организации хранения длинных строк в ДБФ и в СКЛ. А из-за того что в КАМИНе строк очень много появляются проблемы. Поищи на форуме КАМИНа там обсуждали подобные проблемы.

Создаешь документ Табель. Реквизиты: Сотрудник, Подразделение, Сумма, и общий реквизит Данные. В документе, в спец. реквизите, выбираешь помощник, которым хочешь заполнить документ. Открывается еще одна обработка, которая содержит таблицу значений с множеством колонок: Сотрудник, Подразделение, Тариф/Оклад, НормаДней, НормаЧасов, ОтработаноДней, ОтработаноЧасов, ВидНачисления, РайонныйКоэффициен, еще много разных коэффициентов, ИтоговаяСумма. При переносе данных из помощника в документ таблица упаковывается в строку посредствам метода ЗначениеВСтроку и записывается в реквизит документа Данные.   И так в каждом документе: Начисления, Удержания, НДФЛ,....

Так в соседнем топике подобная проблема рассмотрена - строки неограниченной длины д/б в конце списка общих реквизитов

(18) это очень не грамотное хранение данных.
Проще использовать подчиненные документы или справочники.
Всё лучше, чем потеря ссылочности в блобе.

(20) Так это не ТС писал конфу, а Камин. Поди наследие 90-х еще.

(21) А он не читает, что ему пишут...

(20)Согласен.  Или больше видов документов сделать. По кр. мере на фирме эта конфа с начала 2000-х годов. Вначале - очень сырая и ограниченная была. Позже сделали достаточно универсальной. А вот подход к хранению данных прошел через века. Для небольших баз некритично. При расчете в одной базе з/п по большому количеству сотрудников, указанный выше файл со строками неограниченной длины растет очень быстро. Посчитали.. Базе 3 года. Надо оставлять 2 года минимум. Если обрежем, то на те же объемы выйдем менее, чем через год..

(23) Если не путаю, можно настроить КАМИН, чтобы данные строк хранились во внешних файлах.
Погугли.

Надо тот-же архив выгрузить в другую созданную базу на СКл.

Предварительно настроив подключение в конфигураторе и записав после этого пустую константу.

(24)Только если самому дорабатывать ГлобальныйМодуль и помощники.

Пробовал загрузить файл в пустую базу ДБФ. Прошло без проблем. Потом из нее выгружал файл и загружал его в чистую базу на SQL. Возникала та же ошибка. Похоже на строки неограниченной длины.

(0)
Нарыто на просторах инета:

-- есть проводки по непроведенным документам
-- такое безобразие нужно "покоцать"
DELETE FROM _1sentry
WHERE docid IN (SELECT iddoc FROM _1sjourn (nolock)
WHERE closed=0)

-- есть проводки, но нет соответствующих документов
-- такое безобразие нужно "покоцать"
DELETE FROM _1sentry
WHERE docid NOT IN (SELECT iddoc FROM _1sjourn (nolock))

-- есть проводки, но нет соответствующих операций
-- такое безобразие нужно "покоцать"
DELETE FROM _1sentry
WHERE docid NOT IN (SELECT docid FROM _1soper (nolock))

-- есть операции, но нет соответствующих документов
-- такое безобразие нужно "покоцать"
DELETE FROM _1soper
WHERE docid NOT IN (SELECT iddoc FROM _1sjourn (nolock))

-- проверка правильности заполнения DATE_TIME_DOCID в _1sentry
-- вместо проверки - замена на правильный DATE_TIME_DOCID
--select _1sentry.DATE_TIME_DOCID,_1sjourn.DATE_TIME_idDOC
UPDATE _1sentry SET DATE_TIME_DOCID=_1sjourn.DATE_TIME_idDOC
FROM _1sentry (nolock), _1sjourn (nolock)
WHERE _1sentry.DOCID=_1sjourn.idDOC AND
     _1sentry.DATE_TIME_DOCID<>_1sjourn.DATE_TIME_idDOC

После всего этого - удаляешь записи в _1scrdoc.

Как показывает практика - чаще бывают ошибки по последнему запросу.

Загружал точно в другую базу или в ту-же пустую?

(27)
http://www.kaminsoft.ru/cgi-bin/yabb2/YaBB.pl?num=1221540723

Оттуда..

а как дружится 1С с SQL? Камин точно так же. Правда совет - настройте параметр программы "ДлинаСтрокиПомощника" в значение 0, чтобы данные помощников хранились во внешних файлах, ибо SQL не всегда дружит с 1Совскими длинными строками

(0) может самое время на Камин 3.0 переползти?

Вроде еще была фишка, что реквизит неограниченной длины не должен быть последним реквизитом.

(29)Данные скрипты прогонял. Ничего не нашли...

(31)Перед каждой загрузкой создавал новую базу SQL и в нее производил загрузку.

Да, есть настройка ДлинаСтрокиПомощника. Не знал. Раньше вроде числом была забита в конфе.
На что повлияет, если данный параметр будет установлен в 0? Если будет обмен с файлами, то увеличится время доступа? С блокировками могут быть проблемы?

Руководству предоставлены данные о стоимости перехода и ресурсах. Принимают решение...
Скорее всего оставят 7-ку..

Все таки перед выгрузкой надо было ТиИ прошуршать :)

(38)Все таки вы сударь Бездарен :(
Убили 8-ку :(...

(37)Безграничные реквизиты переправь на ограниченные, но оченно длинные. :)
Помогает.

(38)ТиИ?

(40)Решение руководство принимает, т.к. ему за это платить.

Прочитал на форуме, что "для ODBC строки неогранич длины должны быть последними." Это может помочь? Как реализовать? Достаточно перенести реквизит в дереве в низ списка?

(44) Да

Сейчас перенесу вниз реквизит с типом строка неограниченной длины. Сделаю выгрузку/загрузку. Отпишусь о результатах.

(46) Ждёмс.

Как дела?

(0) Автор откликнись! Получилось? У меня у одного клиента точно-такая-же проблема.

(49) Видимо автор погиб под тяжестью непосильной задачи..

(50) В строке неограниченной длины оказалось слишком много буковок и его придавило при попытке перенести вниз.

Разрулил.. Пишу как...

Перевел базу на MSSQL)))

Общий реквизит документов, с типом СтрокаНеограниченнойДлины оказался последним в списке реквизитов. Значит в данном случае помех переносу не оказывал.
Небольшие базы с той же конфигурацией переводились на MSSQL без проблем.
1. Вначале сделал принудительную переиндексацию(чтобы избавиться от возможных накопившихся битых индексов).
2. В базе, Сервис - Параметры программы    установил реквизит ДлинаСтрокиПомощника в 0(чтобы все данные сохранялись в файлах).
3. Воспользовался обработкой, переносящей данные из реквизита "Данные"(тип: строка неограниченной длины) во внешние файлы. Скачать можно здесь:
http://www.kaminsoft.ru/products/nz/members/79-2009-01-04-13-50-28/514--q-q.html
(если закроют ссылку, пишите, пришлю на почту). Применил ее для видов документов Табель и НачСред за все года. В основном из-за них разрослась таблица 1sblob.dbf в базе.
4. Запустил из конфигуратора - Тестирование и исправление базы(с упаковкой таблиц). В результате таблица уменьшилась раз в 5, а директория DATA, в которой хранятся файлы с данными реквизита, в каталоге ИБ, увеличилась примерно на столько же.
5. Поставил компоненту Unload_Dat_Fix, иначе из большой базы не сделать выгрузку данных. Скачать можно здесь: http://x-romix.narod.ru/.
6. В конфигураторе Администрирование - Выгрузить данные.
7. В MSSQL создаю базу. В 1С создаю пустую базу, настраиваю подключение к MSSQL. Загружаю данные.

Похоже проблемы с загрузкой в MSSQL были из-за битых строк неограниченной длины...

(53) Спасибо за подробный отчет!

в базу знаний :)

Реквизит ДлинаСтрокиПомощника нужно установить хотя бы в 1. Если он равен 0, тогда при переносе данных из помощника в документ, возникает ошика(КАМИН воспринимает нуливое значение из данного параметра как пустую строку(""), а потом сравнивает ее с переменной с типом Число).