Делается перевод базы из dbf в sql.
Движок 1с 7.7 релиз 27. SQL 2000.
База dbf размером около 4 ГБ.

При загрузке в 1с sql выдает следующее:

---------------------------
Конфигуратор
---------------------------

SQL State: 23000
Native: 1505
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 1. Most significant primary key is 'MD '.

SQL State: 42000
Native: 1750
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Could not create constraint. See previous errors.

SQL State: 01000
Native: 3621
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated.
---------------------------


Сейчас в тестовой базе dbf запущено ТИИ. Продолжается уже четвертые сутки, неизвестно когда закончится.
Чем можно вылечить побыстрее?

был бы изанчально в скл - элементарно. в дбф - сложнее

Ошибка SQL State: 23000 CREATE UNIQUE INDEX terminated because a duplicate key w

выясните в какой таблице не создается PK

в аналогичной таблице
в дбф базе

найдите замноженные записи, исправте (удалите, сверните,объедините )


и проделайте для всех таблиц дбф проверку на уникальность PK  

если мс скл был >=2005
то можно отключить создание индексов.
создать их после загрузки

У него ТИИ сейчас идёт. Должно сказать, где дубль АйДи.

(4)
в дбф варианте ТИИ не находит и не справляет такого рода ошибки дублей

нужно самостоятельно исправлять

Возвращаясь к вопросу.
ТИИ продожается уже больше 5 суток. Что там делается - ХЗ. В конфигураторе виден только белый экран. Процесс 1с отжирает свои положенные 25% памяти в терминале.

Некоторое время эта база была центральной в РИБ. Думаю, неуникальность ключей возникла при обменах.

(3) Как проверить таблицы на уникальность ключей в дбф?
скл 2000.

Создай новую пустую базу в СКЛ загрузи этот бекап еще раз.

(6)
нужно написать программу
которая проанализирует словарь (1cv7.dd)
и для каждой таблицы проверит уникальность комбинации
значений полей индекса.

анализаторов 1cv7.dd в интрнет должно быть много
может и готовая программа найдется.

(6) зачем так усложнять?
посмотреть профайлером, на создание какого индекса ругался сиквел, и запросом пыддернуть

(9)
знать мало, в какой таблице.
все равно для 1 таблицы писать прогу или для 1000.
к тому же если ошибка не 1 талице придется повторять загрузку.
Лучше сделать комплексно и проверить всю базу.

(0)скачай ConfStat и смотри, че делает пофигуратор в данный момент.
А так, 4 гиговая база - это ни о чем для дбф варианта, и скуль там как бэ не нужон.

Ну и ТиИ не исправит тебе дубли в ИД

можешь смело его прерывать - бесполезная трата времени.

(12) вроде должен сообщить?
(10) достаточно. И писать ничего не надо. Хотя, конечно, можно, и сложного ничего нет...

(14) неа, ни id в sc ни iddoc в 1sjourn не ловит..

дубли т.е

(7) Делал уже и на сервере и локально на ноуте - те же ошибки.

(11) ConfStat ничего не показывает. Подозрительно, что в каталоге базы дата и время изменения файлов висят неизменными практически с самого начала ТИИ. Может, 1с просто зависла в конфигураторе?

(8) Я правильно понял, из 1cv7.dd я беру названия таблиц и список индексов
и таким, например, запросом

   |SELECT  
   |     " + IndexedFields + ",
   |     SUM(1) as Кол
   |FROM
   |    " + Name + "
   |GROUP BY
   |     " + IndexedFields + "

ищу, где есть неуникальные ключи.

(19)
select idddoc, count(*)
from _1sjourn
group by iddoc
having count(*)>1

(20) Выдает пустую таблицу.

(21) а для какой таблицы  он индекс стоил, когда ключи дублировались?

+(22) на крайняк, dts-ом из dbf таблицу импорти, и проверь...

(22) А как посмотреть? Сообщение, которое выходит при загрузке я скопировал в (0).

(24) профайлер на базу натрави... и как встанет - посмотри последние запросы.

(23) что такое dts?

(26) за что в яндексе забанили?

(6) ТИИ  идет так долго если поставили все галочки?  для нахождения дублей вроде достаточно первых двух - переиндексация и физическая целостность..  у меня на подобной базе шло около 6ти часов

Другое дело что 1С77  не умеет загружать файлы близкие к 4м гигам,  тоже выдавал всякие ошибки, но потом все загрузилось через обработку Книга знаний: Плагин для лечения выгрузки и загрузки больших баз в 1С 7.7

Последнее, что выдал профайлер:

If not exists (select * from sysindexes where name='PK__1SUPDTS' and id=object_id('_1SUPDTS'))Alter table _1SUPDTS add constraint PK__1SUPDTS PRIMARY KEY CLUSTERED(DBSIGN,TYPEID,OBJID)

(28) Галочки были поставлены первые 3.

(28) База-то небольшая - выгрузка в zip занимает 300 метров.
В архиве файл 1Cv77.dat - 1.8 Гб.

(29) посмотри в DBF таблицу _1SUPDTS
по всей видимости в ней есть потовряющися по ключу записи. удали их. и снова переноси.

повторяющиеся ключи кстати проще искать в текущей таблице _1SUPDTS на MS SQL соот-щим запросом

(32) А какие там ключи? В 1cv7.dd нет описания таблицы 1SUPDTS.

(34) у тебя в запросе написано DBSIGN,TYPEID,OBJID

(30)  с тремя галками ТИИ  тоже уходило на сутки,  тупо прервал - запустил заново с двумя - нашлись какие-то ошибки и все загрузилось

(35) Нашлось 8 записей с повторяющимися ключами. Попробую удалить лишние и загрузить.

апдейтс вообще можно удалить.

просче текстовик готовый из выгрузки поправить

Удалил лишние записи, загрузка пошла.
Сейчас смотрю в конфигураторе, в строке состояния "Пересчет ссылок по графе отбора ..." начиная с 1750 года. Смотрю в общем журнале без отборов - самый первый документ 01.01.1980.
Откуда такие периоды в пересчете, интересно?

не 1750, а 1749

вернее 1753