[ОТВЕТИТЬ]
15.03.2016 12:45
Zhalex
 
предыстория
После закрытия и обрезки старшей базы ЦО была разослана команда на обрезку баз в подчин.МХ. В последних стала активной кнопка "Обрезать базу", но при инициализации вылетает ошибка - фатальный сбой.....
Код:
ORA-00001: нарушено ограничение уникальности (SUPERMAG.FFCSPEC_PK_)
Что делать дальше не понятно. (1.029.3sp6)

Доп.проблема в "задвоившихся" остатках в МХ (из-за прилетевших компенсационных накладных из ЦО). Так же в каждое МХ прилетели "чужие" компенсац.накладные по всех МХ, а не только своим (локальным, обслуживаемым) - может удалить их, отключив проверки?
Миниатюры
Нажмите на изображение для увеличения
Название: Cut02.JPG
Просмотров: 569
Размер:	57.8 Кб
ID:	7106  
15.03.2016 12:46
Mtirt
 
А если попробовать рассчитать себестоимость перед обрезкой (да, это странно, но судя по именам таблиц нужна именно себестоимость).
15.03.2016 13:08
Zhalex
 
Среднесут.реал и товародвижение были рассчитаны. Это и есть оно? Закладка "Статистика" рассчитывается уже после обрезки?
15.03.2016 13:28
akonev
 
скорее наоборот: очистить расчеты себестоимости.
15.03.2016 13:36
Mtirt
 
Да, тогда - очистить.
15.03.2016 13:38
OlegON
 
И проверить структуру БД. И я бы не стал резать без ооочень веских причин, в число которых, например, не входит уменьшение размера БД.
16.03.2016 14:02
Zhalex
 
Наличие/отсутствие расчета товародвижения никак не сказалось на возникшей ошибке.

Проверка структуры БД (относительно старшей ЦО) ничего похожего не выявила.
Вложения
Тип файла: rar ПроверкаСтруктуры.rar (922 байт, 37 просмотров)
16.03.2016 14:13
akonev
 
Давай ошибку целиком. Скриншотика недостаточно.
На той машине, где запускал должна где-то примерно в таком месте остаться: С:\sm2000\Data\SmErrorLog*.*
17.03.2016 09:00
Zhalex
 
Код:
--------------------------------------------------------
2016.03.17 (четверг) 08:54:04 1.29.3.0
----- Прерывание работы программы -----
сообщение: "ORA-00001: нарушено ограничение уникальности (SUPERMAG.FFCSPEC_PK_)
ORA-06512: на  "SUPERMAG.PCLOSE", line 504
ORA-06512: на  "SUPERMAG.PCLOSE", line 2034
ORA-06512: на  "SUPERMAG.PCLOSE", line 2065
ORA-06512: на  "SUPERMAG.PCLOSE", line 2142
ORA-06512: на  "SUPERMAG.SMTRUNCATEDB", line 4
ORA-06512: на  line 1
"
исключение: Sm.Core.InteropException
hResult: 80040E2Fh; доп. код: 1
источник: Microsoft OLE DB Provider for Oracle

----- Причина исключения, уровень вложения 1 -----
сообщение: "begin Supermag.SMTruncateDb(TO_DATE('20141201','YYYYMMDD'),null); end;"
исключение: Sm.Core.InteropException
hResult: 80004005h; доп. код: 0
источник: SmLibaryBase trace

----- Причина исключения, уровень вложения 2 -----
сообщение: "ORA-00001: нарушено ограничение уникальности (SUPERMAG.FFCSPEC_PK_)
ORA-06512: на  "SUPERMAG.PCLOSE", line 504
ORA-06512: на  "SUPERMAG.PCLOSE", line 2034
ORA-06512: на  "SUPERMAG.PCLOSE", line 2065
ORA-06512: на  "SUPERMAG.PCLOSE", line 2142
ORA-06512: на  "SUPERMAG.SMTRUNCATEDB", line 4
ORA-06512: на  line 1
"
исключение: Sm.Core.InteropException
hResult: 80040E2Fh; доп. код: 1
источник: Microsoft OLE DB Provider for Oracle

----- Причина исключения, уровень вложения 3 -----
сообщение: "begin Supermag.SMTruncateDb(TO_DATE('20141201','YYYYMMDD'),null); end;"
исключение: Sm.Core.InteropException
hResult: 80004005h; доп. код: 0
источник: SmLibaryBase trace
17.03.2016 12:02
-Den-
 
Вот "картинка" SUPERMAG.FFCSPEC_PK_

Предположительно уникальность можно нарушить одинаковым типом и номером документа, надо "прилетевшие" доки смотреть в особенности не предназначенные для данного МХ.
Миниатюры
Нажмите на изображение для увеличения
Название: 4.png
Просмотров: 85
Размер:	33.3 Кб
ID:	7121  
18.03.2016 09:13
akonev
 
так. вот на этом месте идем в "Администратор" на закладку "Периоды" и внимательно смотрим, что там есть с датами, похожими на дату обрезки базы.
смотрю на ENDDATE в ключе. и думается мне, что уникальность нарушается попыткой сделать запись с той же датой закрытия периода, которая уже есть в базе.
22.03.2016 11:02
Zhalex
 
Цитата:
уникальность нарушается попыткой сделать запись с той же датой закрытия периода, которая уже есть в базе.
Если это так, то ошибка в алгоритме закрытия и обрезки БД на подчин.МХ, что неустранимо без разработчиков. Есть ли способ протрассировать/залогировать что за данные пытается записать в таблицу этот алгоритм?

Прилетевшие из ЦО компенсационные накладные не дает удалить проверка "6" (которая не отключается), так как они находятся в закрытом периоде. Остатки на дату закрытия/обрезки периода оказываются задвоенными.
24.03.2016 12:06
akonev
 
и всё-таки.... что на закладке "Периоды" есть?
29.03.2016 15:31
Zhalex
 
Да, в закладке "Периоды" есть одна запись о закрытии периода с обрезкой БД. Запись и в старшей бд и подчин. одинаковая (скрин с записью есть в 1-ом посте).

Проблема решена с помощью ТП Сервис+.
Цитата:
В ходе обрезки в подчиненной базе происходит перенос в аналитические таблицы FFMapRep_ и FFSpec_ компенсационных накладных на восстановление списанных остатков на конец периода, присланных из ЦО. Этот перенос происходит внутри одной транзакции. То есть либо документы появляется в обоих таблицах, либо, если транзакция неуспешна, отсутствуют в обоих таблицах. У клиента в подчиненной базе произошло рассогласование содержимого таблиц FFMapRep_ и FFSpec_, то есть в одной таблице документы есть, в другой нет.

Нужно удалить из FFSpec_ документы, относящиеся к периоду, закрытому на 01.12.2014 и после этого запустить процедуру обрезки подчиненной базы.:
delete from FFSpec_ where EndDate=TO_DATE('20141201','YYYYMMDD');
commit;
Опции темы


Часовой пояс GMT +3, время: 22:34.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.