Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
Gobur Профи
Вступление в Клуб: 06.11.2012
|
Чт Дек 15, 2016 16:41  16.6 |
|
Полезность: Нет оценки
|
Кто нить перешел? Тестирует?
Не было глюков в операции [DAYDOCS].[PROCESS_PORTF]
А именно резкий скачок повремени работы? |
|
 |
svn Профи
Вступление в Клуб: 04.02.2008
|
Чт Дек 15, 2016 18:53   |
|
Полезность: Нет оценки
|
неделю как работаем
была проблема при конвертации фронт менеджера, который мы кстати не используем - ЦФТ присылало патч |
|
 |
Gobur Профи
Вступление в Клуб: 06.11.2012
|
Вс Дек 18, 2016 15:05   |
|
Полезность: Нет оценки
|
проверяйте,кстати, описание приложений которой идет к накату. Для 16.6 сейчас заменили описание на 16.6.03 (когда тестировали было правильное). В итоге на рабочую версия 16.6 поставилась и описание от 16.6.03. При накатах дополнений пришлось танцевать с бубном. |
|
 |
Gobur Профи
Вступление в Клуб: 06.11.2012
|
Пн Дек 19, 2016 12:38   |
|
Полезность: Нет оценки
|
Еще FIneReader 7 почему то сбросил наименования полей документа после наката (в соотвествии). Было такое , почему он это делает? В предыдущие накаты такого не было. |
|
 |
Gobur Профи
Вступление в Клуб: 06.11.2012
|
Пн Дек 19, 2016 14:28   |
|
Полезность: Нет оценки
|
Gobur пишет: | Еще FIneReader 7 почему то сбросил наименования полей документа после наката (в соотвествии). Было такое , почему он это делает? В предыдущие накаты такого не было. |
процедуры все стали инвалидными и синоноимы через кооторые 7-й FR работает. Какой то жестковатый накат в этот раз - хотя в доке вроде ничего нет, что по сканерам что то меняется. |
|
 |
svn Профи
Вступление в Клуб: 04.02.2008
|
Пн Дек 19, 2016 14:54   |
|
Полезность: Нет оценки
|
такаяже фигня, но это из за апгрейда ТЯ скорее всего |
|
 |
nobel Профи
Вступление в Клуб: 28.09.2011
|
Пн Дек 19, 2016 15:09   |
|
Полезность: Нет оценки
|
мы перешли 17-18 декабря.первый день полет нормальный.единственная проблема была что были дубликаты по истории ДОКД(на тестовой схеме обнаружилось).на боевой все исправили и в целом все штатно прошло.
будем смотреть дальше после обновления |
|
 |
VSV056 Участник - экстремал
Вступление в Клуб: 25.11.2010
|
Пн Дек 19, 2016 15:45   |
|
Полезность: Нет оценки
|
1) Как и писали выше, на 6 пункте, ошибка фронт менеджера:
Операция [U20160930_FM_1] 16.6_031. Фронт менеджер.
Обновлена настройка для дистрибутивного продукта "Прием на инкассо и экспертизу наличной валюты и чеков" (0131840004)
Ошибка при исполнении кода через динамический PL/PLUS:
ORA-20999: CLS-OBJECT_NOT_FOUND: Экземпляр "6058524014" не найден, тип [CM_POINT]
ORA-06512: на "IBS.MESSAGE", line 111
ORA-06512: на "IBS.Z#CM_POINT#INTERFACE", line 540
ORA-01403: данные не найдены
begin [CONV_57].[U20160914_FM_1]; end;
ЦФТ присылало исправление.
2. 30 пункт.
1. 14/12/2016 16:33:44.ORA-00039: ошибка при выполнении периодического действия
ORA-04036: Объем памяти PGA, используемой экземпляром, превышает PGA_AGGREGATE_LIMIT
Не хватило памяти на конвертацию обеспечения из PTL_HIST_REC в PTL_HISTORY
3. 31 пункт
14:18:31 CREATE UNIQUE INDEX IDX_Z#PTL_HISTORY_CHKREC
ON IBS.Z#PTL_HISTORY(C_DATE_BEG,C_PRODUCT,C_ZALOG,C_ZALOG_BODY)
TABLESPACE I_USR
PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE ( PCTINCREASE 0
MINEXTENTS 1 MAXEXTENTS 2147483645
FREELISTS 1 FREELIST GROUPS 1
INITIAL 32K NEXT 32K) NOPARALLEL NOCOMPRESS
14:18:31 ORA-01452: CREATE UNIQUE INDEX невозможно; найдены дублирующиеся ключи
14:18:31 IDX_Z#PTL_HISTORY_CHKREC: ORA-01452: CREATE UNIQUE INDEX невозможно; найдены дублирующиеся ключи
14:18:31 Ошибка выполнения отложенного действия: Ошибка создания индекса IDX_Z#PTL_HISTORY_CHKREC
Почему-то задвоились записи, удалил дубли, индекс создался. |
|
 |
VSV056 Участник - экстремал
Вступление в Клуб: 25.11.2010
|
Пн Дек 19, 2016 15:50   |
|
Полезность: Нет оценки
|
В локале PTL_HIST_REC никто не использовал?
По идее надо прошерсить весь локал и переделать на PTL_HISTORY, т.к. операции не сломанные (PTL_HIST_REC пока еще на базе, но не исп. дистрибутивом). |
|
 |
Gobur Профи
Вступление в Клуб: 06.11.2012
|
Пн Дек 19, 2016 17:44   |
|
Полезность: Нет оценки
|
VSV056 пишет: | В локале PTL_HIST_REC никто не использовал?
По идее надо прошерсить весь локал и переделать на PTL_HISTORY, т.к. операции не сломанные (PTL_HIST_REC пока еще на базе, но не исп. дистрибутивом). |
Раньше писали в какой версии удалят. Сейчас нет в доке. Но ЦФТ все свои переписали на новую таблицу. |
|
 |
nobel Профи
Вступление в Клуб: 28.09.2011
|
Вт Дек 20, 2016 07:15   |
|
Полезность: Нет оценки
|
VSV056 пишет: | В локале PTL_HIST_REC никто не использовал?
По идее надо прошерсить весь локал и переделать на PTL_HISTORY, т.к. операции не сломанные (PTL_HIST_REC пока еще на базе, но не исп. дистрибутивом). |
У нас использовалась данная таблица в локальных операциях.Пришлось переписать код(часть своих функции,часть использовать дистрибутив) |
|
 |
VSV056 Участник - экстремал
Вступление в Клуб: 25.11.2010
|
Вт Дек 20, 2016 07:26   |
|
Полезность: Нет оценки
|
nobel пишет: | VSV056 пишет: | В локале PTL_HIST_REC никто не использовал?
По идее надо прошерсить весь локал и переделать на PTL_HISTORY, т.к. операции не сломанные (PTL_HIST_REC пока еще на базе, но не исп. дистрибутивом). |
У нас использовалась данная таблица в локальных операциях.Пришлось переписать код(часть своих функции,часть использовать дистрибутив) |
Как отлавливали все локальные операции с использованием PTL_HIST_REC? Поиск по коду мне не нравится, можно что-то упустить.
Думаю что надо на тесте как-то сломать тип PTL_HIST_REC и перекомпилить все объекты, тогда будет 100% картина. Но т.к. тип дистрибутивный, делать придется напрямую в базе а не через администратор словаря. |
|
 |
nobel Профи
Вступление в Клуб: 28.09.2011
|
Вт Дек 20, 2016 10:36   |
|
Полезность: Нет оценки
|
VSV056 пишет: | nobel пишет: | VSV056 пишет: | В локале PTL_HIST_REC никто не использовал?
По идее надо прошерсить весь локал и переделать на PTL_HISTORY, т.к. операции не сломанные (PTL_HIST_REC пока еще на базе, но не исп. дистрибутивом). |
У нас использовалась данная таблица в локальных операциях.Пришлось переписать код(часть своих функции,часть использовать дистрибутив) |
Как отлавливали все локальные операции с использованием PTL_HIST_REC? Поиск по коду мне не нравится, можно что-то упустить.
Думаю что надо на тесте как-то сломать тип PTL_HIST_REC и перекомпилить все объекты, тогда будет 100% картина. Но т.к. тип дистрибутивный, делать придется напрямую в базе а не через администратор словаря. |
Я через поиск отлавливал.Только нужно искать не только сам тип но и реквизит в договорах обеспечения. У нас благо мало было таких операций-за один управились. |
|
 |
Эмиралька Эксперт
Вступление в Клуб: 09.11.2015
|
Пн Дек 26, 2016 05:16   |
|
Полезность: 1
|
nobel пишет: | VSV056 пишет: | nobel пишет: | VSV056 пишет: | В локале PTL_HIST_REC никто не использовал?
По идее надо прошерсить весь локал и переделать на PTL_HISTORY, т.к. операции не сломанные (PTL_HIST_REC пока еще на базе, но не исп. дистрибутивом). |
У нас использовалась данная таблица в локальных операциях.Пришлось переписать код(часть своих функции,часть использовать дистрибутив) |
Как отлавливали все локальные операции с использованием PTL_HIST_REC? Поиск по коду мне не нравится, можно что-то упустить.
Думаю что надо на тесте как-то сломать тип PTL_HIST_REC и перекомпилить все объекты, тогда будет 100% картина. Но т.к. тип дистрибутивный, делать придется напрямую в базе а не через администратор словаря. |
Я через поиск отлавливал.Только нужно искать не только сам тип но и реквизит в договорах обеспечения. У нас благо мало было таких операций-за один управились. |
Код: | select * from dependencies d, methods ing
where referencing_id = ing.id and referenced_id = 'PTL_HIST_REC' |
|
|
 |
VSV056 Участник - экстремал
Вступление в Клуб: 25.11.2010
|
Пн Янв 23, 2017 15:40   |
|
Полезность: Нет оценки
|
Коллеги, доброго дня!
Среди тех кто перешел на 16.6 на боевой у всех все нормально с минимизированными кредитами? В нашем случае, если это линия и у нее более 1 договора обеспечения, сумма обеспечения приходящаяся на договор, вычисляется неверно.
ЦФТ признали дефект, ожидаем исправления. |
|
 |
|