При загрузке данных УРБД выдаётся такая ошибка.

SQL State: 23000
Native: 2627
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint 'PK_DT2196'. Cannot insert duplicate key in object 'dbo.DT2196'. The duplicate key value is (         , 1).

Главная непонятка - откуда значение ключа (         , 1).
То есть с пустым IDDOC
Файл обмена выглядит нормально, все идентификаторы на месте.
MSSQL 2012, 1C7.7 секретный релиз.

Может кто сталкивался с такой проблемой?

(0)База битая.
С dbf такое оч часто случается.
Смотри в dbf DT2196 похоже у тебя она битая.
сперва сдалай на dbf версии ТИИ а птом повторную выгрузку.

распределнка вся на SQL?
или переферийки на dbf?

(1) Вся на SQL. И периферийки и центральная.
DBCC CHECKDB говорит, что всё нормально.
DBCC CHECKTABLE (DT2196) тоже ошибок не выдаёт
Индекс PK_DT2196 перестаивал средствами SQL.
Непонятно откуда берётся пустой IDDOC. Если бы проблема была в файле обмена, тогда бы, наверное, ругнулся сначала на DН2196 (шапку документа).

Самое туманное - откуда берётся пустой IDDOC. Если бы выдал какой-то IDDOC, тогда понятно - висячие строки в таблице. Почистил и заработало. А так, непонятно даже куда копать.
До обмена пустого IDDOC в таблице нет, он откуда-то берётся в процессе обмена.

Сейчас еще с одной периферийкой ошибка возникла.
Все ошибки возникают на табличных частях документов ПКО и СтрокаВыпискиРасход.
Табличная часть у них выглядит так:
#===============================================================================
#==TABLE no 258    : Документ (Мн.ч.) СтрокаВыпискиРасход
# Name    |Descr                         |SQLTableNam|RecordLock
T=DT3274  |Документ (Мн.ч.) СтрокаВыписки|DT3274     |
#-----Fields-------
# Name                  |Descr               |Type|Length|Precision
F=IDDOC                 |ID Document's       |C   |9     |0
F=LINENO_               |LineNo              |S   |0     |0
F=SP53529               |(P)Документ         |C   |13    |0
F=SP160496              |(P)СуммаПоДокументу |N   |14    |2
#----Indexes------
# Name                           |Descr         |Unique|Indexed fields
I=PK_DT3274                      |of IDDOC+LineN|1     |IDDOC,LINENO_

Удаление и создание индекса PK_DT2196 не помогает.

количество строк какое хоть ?

(7) Одна строка. Вот трасса профайлера (на сколько понимаю) загрузки проблемного вида документов:
exec sp_executesql N'Insert into _1SJOURN values( P1,@P2,@P3,@P4,@P5,@P6,@P7,@P8,@P9,P10,P11,P12,P13,P14,P15,P16,P17,P18,P19,@P20,@P21,@P22,@P23,@P24,@P25,@P26,@P27,@P28,@P29,@P30,@P31,@P32,@P33,@P34,@P35,@P36,@P37,@P38,@P39,@P40,@P41,@P42,@P43,@P44,@P45,@P46,@P47,@P48,@P49,@P50,@P51,@P52,@P53,@P54,@P55,@P56,@P57,@P58,@P59,@P60)',N'P1 int,@P2 varchar(9),@P3 int,@P4 smallint,@P5 varchar(23),@P6 varchar(18),@P7 varchar(10),@P8 tinyint,@P9 bit,P10 int,P11 int,P12 bit,P13 bit,P14 bit,P15 bit,P16 bit,P17 bit,P18 bit,P19 bit,@P20 bit,@P21 bit,@P22 bit,@P23 bit,@P24 bit,@P25 bit,@P26 bit,@P27 bit,@P28 bit,@P29 bit,@P30 bit,@P31 bit,@P32 bit,@P33 bit,@P34 bit,@P35 bit,@P36 bit,@P37 bit,@P38 bit,@P39 bit,@P40 varchar(9),@P41 varchar(9),@P42 varchar(9),@P43 varchar(9),@P44 varchar(9),@P45 varchar(9),@P46 numeric(1,0),@P47 numeric(1,0),@P48 varchar(80),@P49 datetime,@P50 varchar(9),@P51 varchar(9),@P52 varchar(9),@P53 datetime,@P54 datetime,@P55 varchar(40),@P56 varchar(13),@P57 varchar(13),@P58 tinyint,@P59 tinyint,@P60 tinyint',1896,'  E0R9ПЕР',2196,53,'201411186BW380  E0R9ПЕР','      33762014    ','МП00000985',5,0,9,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,'    GRПЕР','     0   ','    1RЦБ ','    1WЦБ ','     CЦБ ','     0   ',0,0,'                                                                                ','1753-01-01 00:00:00','     0   ','     0   ','     0   ','1753-01-01 00:00:00','1753-01-01 00:00:00','                                        ',' 1P0  E0R8ПЕР','   0     0   ',1,0,0
go
declare @p1 int
set @p1=NULL
exec _1sp__1SJOURN_MaxRowID @p1 output
select @p1
go
exec sp_executesql N'Insert into DH2196 values(
P1,@P2,@P3,@P4,@P5,@P6,@P7,@P8,@P9,P10,P11,P12,P13,P14,P15,P16,P17,P18,P19,@P20,@P21,@P22,@P23,@P24,@P25,@P26,@P27,@P28,@P29,@P30,@P31,@P32,@P33,@P34,@P35,@P36,@P37,@P38,@P39,@P40,@P41,@P42,@P43,@P44,@P45,@P46,@P47,@P48,@P49,@P50,@P51,@P52,@P53,@P54,@P55)',N'P1
varchar(9),@P2 varchar(13),@P3 varchar(9),@P4 varchar(9),@P5 varchar(9),@P6 varchar(9),@P7 varchar(9),@P8 varchar(9),@P9 numeric(9,4),P10 numeric(7,0),P11 numeric(14,2),P12 varchar(9),P13 numeric(1,0),P14 varchar(9),P15 numeric(14,2),P16 varchar(80),P17 varchar(64),P18 varchar(150),P19 varchar(23),@P20 varchar(3),@P21 varchar(23),@P22 varchar(3),@P23 varchar(23),@P24 varchar(3),@P25 varchar(23),@P26 varchar(3),@P27 varchar(23),@P28 varchar(3),@P29 varchar(23),@P30 varchar(3),@P31 varchar(23),@P32 varchar(3),@P33 varchar(23),@P34 varchar(3),@P35 varchar(9),@P36 numeric(1,0),@P37 numeric(6,0),@P38 varchar(9),@P39 varchar(9),@P40 numeric(1,0),@P41 numeric(1,0),@P42 numeric(1,0),@P43 datetime,@P44 varchar(9),@P45 datetime,@P46 datetime,@P47 varchar(9),@P48 numeric(1,0),@P49 numeric(1,0),@P50 numeric(1,0),@P51 numeric(1,0),@P52 numeric(1,0),@P53 numeric(1,0),@P54 varchar(13),@P55 text','  E0R9ПЕР',' 18R  E0QFПЕР','    1AЦБ ','   1MN   ','   K0YЦБ ','   MKJПЕР','     0   ','     1   ',1.0000,1,6137.10,'     0   ',0,'     0   ',6137.10,'Физическое лицо                                                                 ','Реализация (купля-продажа) №5615 от 18.11.14                    ','                                                                                                                                                      ','B1 1PP     0   ','1  ','U                      ','   ','U                      ','   ','U                      ','   ','B1 1PP     0   ','1  ','U                      ','   ','U                      ','   ','U                      ','   ','     2   ',0,3683,'     0   ','     0   ',0,1,0,'2014-11-19 00:00:00','    GRПЕР','2014-11-18 00:00:00','1753-01-01 00:00:00','     0   ',0,0,0,0,1,0,' 18R  E0QFПЕР',''
go
declare @p1 int
set @p1=-1
exec sp_prepexec @p1 output,N'P1 varchar(9)',N'Delete from DT2196 where IDDOC=P1','  E0R9ПЕР'
select @p1
go
exec sp_executesql N'Insert into DT2196 values( P1,@P2,@P3,@P4)',N'P1 varchar(9),@P2 smallint,@P3 varchar(13),@P4 numeric(14,2)','         ',1,' 18R  E0QFПЕР',0.00
go

(0) Проверь базу с помощью Поиск Ошибок в регистрах.
моя обработка есть на инфостарте
там вроде есть проверки на dh и dt

Вроде сначала всё нормально. Документ с внутренним ИД E0R9ПЕР записывается сначала в _1SJOURN, потом в DH2196. Дальше удаляются возможные строки из DT2196. Все проходит нормально. ПОтом вдруг возникает пустой IDDOC
exec sp_executesql N'Insert into DT2196 values( P1,@P2,@P3,@P4)',N'P1 varchar(9),@P2 smallint,@P3 varchar(13),@P4 numeric(14,2)','         ',1,' 18R  E0QFПЕР',0.00

Где то у тебя есть пустая дата

в журнальчике

(11) Как проверить?
select TOP(100) * from _1SJOURN WITH (NOLOCK) order by DATE_TIME_IDDOC
визуально проблем не обнаруживает

на 1753 проверь дату

и это, проблемный документ с каким временем у тебя ? строк в нём сколько ?

(14) минимальное значение в DATE_TIME_IDDOC стоит '19000101   7PS  39YAОР '
В этом году всякие служебные непроводимые документы хранятся.
(15) Проблемных документов, похоже, несколько. И разных видов. Одно общее - они все либо ПКО, либо СтрокаВыпискиРасход, у которых однотипная табличная часть. см (5).
(9) А что проверяет у тебя пункт 6.4? Он сравнивает дату движения с ACCDATE из 1SSYSTEM. Там же, как я понимаю, хранится текущий период бух.итогов. Зачем сравнивать его с датами движений?

(15) Во всех проблемных документах одна строка.

(9) С пунктом 6.1 тоже категорически непонятно, что и зачем он делает.

(18) как зачем документы с путой датой а точнее с датой
01.01.1753 могут иметь еще и движения
этот пункт как раз такое и ищет.
ну и как бы дата движения не может быть меньше даты первого документа.

6.4 тоже самое только где есть галка быстрые движения

(19) Да, но из _1system берётся дата accdate, которая содержит текущий бухгалтерский период. То есть, сейчас, 4 квартал 2014 года.

В трассе профайлера при загрузке проблемного документа видится странная вещь. Перед загрузкой удаляются связанные записи этого документа в различных таблицах. Наблюдаются запросы на delete к регистрам, операциям, проводкам, шапке документа, _1SCRDOC, _1SACCSEL, _1SSBSEL и всему прочему.
Но ни где не могу найти удаление записи по IDDOC в _1SJOURN перед тем, как делается Insert into _1SJOURN ...

Не, вру. Нашлось удаление. По ROW_ID удаляет

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

(20) Ошибка у меня.
Писал по своей базе где только регисты и ошибочно интерпретировал что поле accdate это наименьшая дата документа

(0) Копия базы с ошибкой осталось ?
Был уверен что в (9) есть проверка на связь dt и dh
оказалось что нет этого в 9 ( скорее всего написал
это и  стер  а в голове осталось)

Как бы условие как раз что у тебя
Если в DT есть IDDOC и нет этого  IDDOC в DH
то это ошибка ( на 99% это ситуация из subj )

ну и еще можно написать проверки dh и _1sjourn
ну и еще можно написать проверки dt и _1sjourn

если надо могу дописать эту проверку

(25) Бэкапы есть, конечно. Но мне второй рабочий день на разборки тратить жалко. Вылечилось и ладно.
>> Если в DT есть IDDOC и нет этого  IDDOC в DH
Сомнительно. Содержимое _1SJOURN, DT, DH по ID незагружающегося документа я смотрел через Management Studio. Всё было.
К тому же, ошибки связи DT, DH и прочие аналогичные обновление конфигурации с реструктуризацией не лечит. А тут проблема исчезла (надеюсь, тьфу-тьфу-тьфу).

Основное подозрение на какие-то несоответствие MD, DDS и базы. Потому что как раз перед этим делал подмену MDшника. Но структура базы не менялась. В проблемных видах документов структура базы соответствовада DDS. Чем подменённый МД оказался не такой, как штатно загруженный - загадка.

(16) >>>>  минимальное значение в DATE_TIME_IDDOC стоит '19000101   7PS  39YAОР '

Вот твоя ошибка, грохни её :)

+(27) "И что за привычка на скуле сдвигать значения дат?" :)

(27) Да там вся база сплошная моя ошибка. Многолетней выдержки, как вино :)
(28) >> "И что за привычка на скуле сдвигать значения дат?"
Эээээ... Если в этом высказывании есть какой-то смысл, то я его не понял. Поясни.