проблема следующего характера
выгружаю из dbf в sql.
получаю:
Ошибка SQL State: 23000 Native: 1505
Нашел на форуме решение в случае, если такое уже произошло с рабочей базой.
http://www.forum.mista.ru/topic.php?kb=1&id=9962
Но в моем случае это не прокатит,  ибо загрузка прерывается, и мне в любом случае придется заново подгружать файл выгрузки, что автоматически сотрет (как я понимаю) все изменения.
Тестирование и исправление исходной dbf базы делал. бестолку. все также.
Правда не делал пересчет итогов. Ибо на одной из копий поставил и процесс висит до сих пор ~ более 4 суток.
Что думаю сделать.. попробую в исходной dbf базе упаковать таблицы. вдруг поможет..
А что посоветуют профи 1с?

http://msdn.microsoft.com/ru-ru/library/cc280634(v=sql.105).aspx

добейтесь уникальности ключа

Ты бы текст своей ошибки написал.

(1) Михаил, спасибо за очень интересную ссылку.
Но вот, скажем, я загружаю, получил ошибку. исправил в недовыгруженной базе все согласно мануала. Потом мне нужно будет все же еще раз загрузить файлик выгрузки из ДБФ, и это автоматически очистит базу. В итоге, я опять вернусь в начало...

(2)
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 2. Most significant primary key is ' 2WAUGT'.

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

(3) чистить надо в дбф, потом грузить.

(3) Ну об этом нада было раньше думать. Посмотрите дубли в дбф, исправьте и потом тяните в скуль. Но можете конечно сделать по своему, никто вам незапретит.

(0)Запусти сперва ТиИ, а потом уже выгружай и загружай :)
+ И бекап, обязательно перед ТиИ, мало ли.

(3) Насколько я помню, данные сначала загружаются, а потом делаются индексы. Т.е. ты можешь поправить в загруженной SQL-ой версии.

ТиИ запускать не надо, тем более, что оно никогда не лечило дубли в ID или IDDOC..

Надо всего лишь найти дубли в самому.

(7) Делал первым же делом. (правда как сказал выше в виду трудоемкости процесса без пересчета итогов)  Делал даже упаковку таблиц. Но бестолку.
Что попытался сделать.
так как:
CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is ' 2WAUGT'. и в не монопольном входе 1Ска ругается на 1SJOURN. открыл 1Cv7.DDS и нашел в нем описание индексов таблицы 1SJOURN
вот кусок
#===============================================================================
#==TABLE no 3      : Журналы
# Name    |Descr                         |SQLTableNam|RecordLock
T=1SJOURN |Журналы                       |_1SJOURN   |R        
#-----Fields-------
# Name                  |Descr               |Type|Length|Precision
F=ROW_ID                |Row ID              |I   |0     |0        
F=IDJOURNAL             |ID of Journal       |I   |0     |0        
F=IDDOC                 |ID Document         |C   |9     |0        
F=IDDOCDEF              |ID Def Document     |I   |0     |0        
F=APPCODE               |App code            |S   |0     |0        
F=DATE_TIME_IDDOC       |Date+Time+IDDoc     |C   |23    |0        
F=DNPREFIX              |Prefix Document No  |C   |18    |0        
F=DOCNO                 |Document No         |C   |10    |0        
F=CLOSED                |Flag document is clo|Y   |0     |0        
F=ISMARK                |Doc is Marked for De|L   |0     |0        
F=ACTCNT                |Action counter      |I   |0     |0        
F=VERSTAMP              |Version stamp       |I   |0     |0        
F=RF639                 |Reg Action Flag     |L   |0     |0        
F=RF464                 |Reg Action Flag     |L   |0     |0        
F=RF4667                |Reg Action Flag     |L   |0     |0        
F=RF4674                |Reg Action Flag     |L   |0     |0        
F=RF635                 |Reg Action Flag     |L   |0     |0        
F=RF3549                |Reg Action Flag     |L   |0     |0        
F=RF4343                |Reg Action Flag     |L   |0     |0        
F=RF405                 |Reg Action Flag     |L   |0     |0        
F=RF328                 |Reg Action Flag     |L   |0     |0        
F=RF351                 |Reg Action Flag     |L   |0     |0        
F=RF2964                |Reg Action Flag     |L   |0     |0        
F=RF4335                |Reg Action Flag     |L   |0     |0        
F=RF4314                |Reg Action Flag     |L   |0     |0        
F=RF2351                |Reg Action Flag     |L   |0     |0        
F=RF438                 |Reg Action Flag     |L   |0     |0        
F=RF4480                |Reg Action Flag     |L   |0     |0        
F=RF8901                |Reg Action Flag     |L   |0     |0        
F=RF9070                |Reg Action Flag     |L   |0     |0        
F=RF9095                |Reg Action Flag     |L   |0     |0        
F=RF9119                |Reg Action Flag     |L   |0     |0        
F=RF9270                |Reg Action Flag     |L   |0     |0        
F=SP74                  |(P)Автор            |C   |9     |0        
F=SP798                 |(P)Проект           |C   |9     |0        
F=SP4056                |(P)Фирма            |C   |9     |0        
F=SP5365                |(P)ЮрЛицо           |C   |9     |0        
F=DS1946                |Flag document in seq|Y   |0     |0        
F=DS4757                |Flag document in seq|Y   |0     |0        
F=DS5722                |Flag document in seq|Y   |0     |0        
#----Indexes------
# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK__1SJOURN                    |ROW_ID        |1     |ROW_ID                                                      |1          
I=IDDOC                          |Id Doc        |1     |IDDOC                                                       |0          
I=ACDATETIME                     |Date+Time+ID  |1     |DATE_TIME_IDDOC                                             |0          
I=DOCNO                          |Prefix+No     |1     |DNPREFIX,DOCNO,ROW_ID                                       |0          
I=DOCTYPE                        |Type+Date+Time|1     |IDDOCDEF,DATE_TIME_IDDOC                                    |0          
I=JOURNAL                        |Journal+Date+T|1     |IDJOURNAL,DATE_TIME_IDDOC                                   |0          
I=VIA74                          |VIA74         |1     |SP74,DATE_TIME_IDDOC                                        |0          
I=VIA798                         |VIA798        |1     |SP798,DATE_TIME_IDDOC                                       |0          
I=VIA4056                        |VIA4056       |1     |SP4056,DATE_TIME_IDDOC                                      |0          
I=VIA5365                        |VIA5365       |1     |SP5365,DATE_TIME_IDDOC                                      |0          
I=VIA1946                        |VIA1946       |0     |DS1946,DATE_TIME_IDDOC                                      |0          
I=VIA4757                        |VIA4757       |0     |DS4757,DATE_TIME_IDDOC                                      |0          
I=VIA5722                        |VIA5722       |0     |DS5722,DATE_TIME_IDDOC                                      |0  
-----------------------------------------------------
судя по Ошибка SQL State: 23000 Native: 1505 - мое решение проблемы   получаем что ID2 создается по IDDOC. написал такой скрипт

SELECT [ROW_ID],
      [IDDOC],
      [DATE_TIME_IDDOC],
      [DNPREFIX],
      [DOCNO],
      [IDDOCDEF],
      [IDJOURNAL]
FROM [trade].[dbo].[_1SJOURN]
WHERE [IDDOC] like '%2WAUGT%'                                                      

но ничего не выдает.
открыл в анализаторе таблицу _1SJOURN --- она пустая (((

П..ц

я думал может здесь найду упоминание, отсылку, подсказку, что искать в dbf базе. Ибо с поиском т.н. дублей в базах не сталкивался.

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

Размер файла выгрузки озвучь

(12) тебе скуль пишет в какой конкретно табличке дубли, если в 1sjourn, то тупо смотришь в дбф дубли в файле 1sjourn простейшим запросом select * from 1sjourn group by iddoc having count(iddoc)>1

+ в дбф базе нужно как минимум, в общие реквизиты с типом строка неогр. длины сделать последними в списке перед выгрузкой, + избавится от пустых дат в 1sjourn(если такие есть)

я думал он сначала загружает таблицу, а уже потом её индексирует... и натыкается на 2 одинаковых значения в поле IDDOC (поэтому считал что там не должно быть пусто)

(15) ааа вот как! Спасибо!!! Пробую!

ура-ура-ура
Ёпрст, огромное спасибо.
залез в 1sjourn.dbf нашел два дока от 13.01.12 с одинаковым iddoc. это две с/ф на одну и ту же реализацию выбитые разными операторами.