v7: The duplicate key value в 1С7.7 SQL #726261

При загрузке данных УРБД выдаётся такая ошибка. 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 секретный релиз. Может кто сталкивался с такой проблемой?

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

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

Вся на 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 не помогает.

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

Одна строка. Вот трасса профайлера (на сколько понимаю) загрузки проблемного вида документов: exec sp_executesql N'Insert into _1SJOURN values( ,@P2,@P3,@P4,@P5,@P6,@P7,@P8,@P9,0,1,2,3,4,5,6,7,8,9,@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' int,@P2 varchar,@P3 int,@P4 smallint,@P5 varchar,@P6 varchar,@P7 varchar,@P8 tinyint,@P9 bit,0 int,1 int,2 bit,3 bit,4 bit,5 bit,6 bit,7 bit,8 bit,9 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,@P41 varchar,@P42 varchar,@P43 varchar,@P44 varchar,@P45 varchar,@P46 numeric(1,0),@P47 numeric(1,0),@P48 varchar,@P49 datetime,@P50 varchar,@P51 varchar,@P52 varchar,@P53 datetime,@P54 datetime,@P55 varchar,@P56 varchar,@P57 varchar,@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 set @p1=NULL exec _1sp__1SJOURN_MaxRowID @p1 output select @p1 go exec sp_executesql N'Insert into DH2196 values( ,@P2,@P3,@P4,@P5,@P6,@P7,@P8,@P9,0,1,2,3,4,5,6,7,8,9,@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' varchar,@P2 varchar,@P3 varchar,@P4 varchar,@P5 varchar,@P6 varchar,@P7 varchar,@P8 varchar,@P9 numeric(9,4),0 numeric(7,0),1 numeric(14,2),2 varchar,3 numeric(1,0),4 varchar,5 numeric(14,2),6 varchar,7 varchar,8 varchar,9 varchar,@P20 varchar,@P21 varchar,@P22 varchar,@P23 varchar,@P24 varchar,@P25 varchar,@P26 varchar,@P27 varchar,@P28 varchar,@P29 varchar,@P30 varchar,@P31 varchar,@P32 varchar,@P33 varchar,@P34 varchar,@P35 varchar,@P36 numeric(1,0),@P37 numeric(6,0),@P38 varchar,@P39 varchar,@P40 numeric(1,0),@P41 numeric(1,0),@P42 numeric(1,0),@P43 datetime,@P44 varchar,@P45 datetime,@P46 datetime,@P47 varchar,@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,@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 set @p1=-1 exec sp_prepexec @p1 output,N' varchar',N'Delete from DT2196 where IDDOC=','  E0R9ПЕР' select @p1 go exec sp_executesql N'Insert into DT2196 values( ,@P2,@P3,@P4)',N' varchar,@P2 smallint,@P3 varchar,@P4 numeric(14,2)','         ',1,' 18R  E0QFПЕР',0.00 go

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Копия базы с ошибкой осталось ? Был уверен что в есть проверка на связь dt и dh оказалось что нет этого в 9 ( скорее всего написал это и  стер  а в голове осталось) Как бы условие как раз что у тебя Если в DT есть IDDOC и нет этого  IDDOC в DH то это ошибка ( на 99% это ситуация из subj ) ну и еще можно написать проверки dh и _1sjourn ну и еще можно написать проверки dt и _1sjourn если надо могу дописать эту проверку

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

>>>>  минимальное значение в DATE_TIME_IDDOC стоит '19000101   7PS  39YAОР ' Вот твоя ошибка, грохни её :)

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

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