gifts2017

Глюки со временем документа в таблицах 1С (SQL Server)

Опубликовал Маргарита (leoner61) в раздел Администрирование - Тестирование и исправление

При загрузке в монопольном режиме 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 2. Most significant primary key is ' 20MGJ '.

 

 

Проблема такая: при обновлении конфигурации на этапе пересчёта перекрёстных ссылок 1С ругается 
"CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2" и умирает. 
Фишка в том, что она сначала напихивает записей в _1scrdoc, а потом уже создаёт уникальный индекс, 
который не желает создаваться, т.к. 1С неправильно заполнила таблицу.

 

Решение:

1 Ищем средствами SQL Server Management Studio в таблицах _1SJOURN (Журналы  документов) , _1SOPER и _1sentry не соответствие по времени(проверка_time.sql)

select
o.date_time_docid dto,
s.date_time_docid dtsj,

o.docid [Документ $Документ],
j.iddocdef Документ_вид,
j.docno номер,
j.date_time_iddoc dtj

from _1SOPER o (NOLOCK)
inner join _1sentry s (NOLOCK) ON s.docid = o.docid
inner join _1SJOURN j (NOLOCK) ON j.iddoc = o.docid

where (s.date_time_docid <> o.date_time_docid)

order by o.date_time_docid

Если таковые записи есть,то есть несоответствие по времени и 1с при пересчете перекрестных ссылок документов (формирование таблицы документов  _1SCRDOC) создаст дубликаты ключей. 

Т.е. получается, что в журнале документов данный документ (ручная операция) имеет одно время, а в списке операций - другое... Почему такое происходит я не знаю, но примерно могу догадаться, проанализировав значение времени:
20131031EAEAY8 20MGJ   20131031EAGG40 20MGJ   20MGJ   12120  870               20131031EAEAY8 20MGJ   
20131031EAEAY8 = 10.31.2013 23:59:59
20131031EAGG40 = 10.31.2013 23:59:59 + 10 секунд

2 Устанавливаем дату:время  в таблице  проводок из журнала  документов средствами  SQL:

update _1sentry
set _1sentry.DATE_TIME_DOCID=_1sjourn.DATE_TIME_IDDOC

FROM _1sjourn(nolock)
where _1sentry.DOCID=_1sjourn.idDOC and
_1sentry.DATE_TIME_DOCID<>_1sjourn.DATE_TIME_idDOC

3 Прописываем по  таким  документам "дату:время" в журнале (ссылки документов)  _1SCRDOC  из таблицы _1SJOURn

update _1scrdoc
set _1scrdoc.child_date_time_iddoc=_1sjourn.DATE_TIME_IDDOC
FROM _1sjourn(nolock)
where _1scrdoc.childid=_1sjourn.idDOC

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
проверка_time.sql
.sql 0,40Kb
27.01.15
2
.sql 0,40Kb 2 Скачать
SQLQuery4updatescrdocTIME.sql
.sql 0,14Kb
27.01.15
1
.sql 0,14Kb 1 Скачать
SQLQuery3updatejornTIME.sql
.sql 0,19Kb
27.01.15
1
.sql 0,19Kb 1 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Aikosyapr (aikosyapr) 22.05.15 10:40
Спасибо, добрый человек, весьма помог
2. Павел Зайчук (pavz) 26.05.16 09:48
Да, столкнулся с данной проблемой при реструктуризации, решал СРОЧНО устранением задвоенных по ключевым полям записей в 1SCRDOC.
Данное решение правильнее на порядок! т.к. устраняет причину для уже имеющихся в базе документов).
СПАСИБО!
3. Павел Зайчук (pavz) 26.05.16 17:08
Однако, все равно пришлось в неиндексируемом 1SCRDOC задвоенные записи уничтожать по своему. можно было запустить перепостроение и проблема бы ушла, но база большая, долго.
leoner61; +1 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа