Галактика в вопросах и ответах

Проблема стара, но что-то решения на форуме не нахожу.
После расчет зп по вновь принятым выходит ошибка:
Ошибка при работе с таблицей "Размер годового дохода после расчета зарплаты(тек)"6397
[x] Ошибка выполнения [310]
Таблица SUMULTEC ("После расчета зарплаты(Тек)")
И, соответственно, при попытке зайти в кнопку "Размер годового дохода" (после з/п) выдается ошибка: Дублирование ключа. Таблица N16062
Платформа оракл. Что делать

Это происходит, если вы принимаете человека на тот же табельный номер, но в другое подразделение. Там проблемы с ключом возникают. Исправить можно суппортом поле CEX. Или сделайте в ЗП перевод сотрудника сначала в старое подразделение (из которого он увольнялся), а потом верните в новое.
Мы всех повторно принятых принимаем на новые табельные.

s2176 писал(а):Это происходит, если вы принимаете человека на тот же табельный номер, но в другое подразделение.

Нет. Сотрудники принимаются на другой табельный номер. Кроме того, есть люди которых вообще нет в базе, ошибка по всем именно вновь принятым.
Ситуация просто похожа с той которая у вас возникла.

Исправить можно суппортом поле CEX.

Что все-таки нужно исправлять в таблице SUMULTEC и как?

#declare dddd(tablename)
update #tablename where (( #tablename.tabn == lschet.tabn ))
and ( #tablename.cex<>lschet.cex or #tablename.clsch<>lschet.nrec)
set #tablename.cex:=lschet.cex ,#tablename.clsch:=lschet.nrec;

#end

#DDDD(SUMULTEC)
#DDDD(SUMULPRO)
#DDDD(SUMULBUD)
#DDDD(SUMULSOC)
#DDDD(SUMUPSOC)
#DDDD(SUMUPTEC)
#DDDD(SUMUPPRO)
#DDDD(SUMUPBUD)
#DDDD(DOPNAL2)
#DDDD(DOPNAP2)
#DDDD(DOPNAL)
#DDDD(DOPNAP)
#DDDD(ARXTAR)

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

edward_K писал(а):Стандартный способ сделать сжатие бд - но оно не дает никаких протоколов - молча удаляет все кривые записи(даже если их еще можно спасти и они нужны).

Запустил функцию
Расчет зарплаты - Сервисные функции - Сжатие базы данных
на тестовой базе. Еще есть варианты, чтоб без удаления лишнего?

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

Голова не соображает к вечеру. Вот есть человек, которого в базе нет, принимаем его на работу. Записи в таблице SUMULTEC с таким табельным нет. В какой момент изменения цеха не произошло? Что в таблице вообще можно посмотреть/удалить (будет делать сервисная функция), если нету там такого табельного.

запускайте мой лот и не партесь. сжатием лучше не пользоваться. Вообще возможно у вас не корректно установлена связь между структурными единицами и подразделениями. Persons.galdep проверте после приема - должно равняться lschet.cex. А тробла на всех принятых? Вообще пора убегать на 8.1.

edward_K писал(а):запускайте мой лот и не партесь.Persons.galdep проверте после приема - должно равняться lschet.cex. А тробла на всех принятых?

Запускать в модуле SQL - sql - ввод? Поле проверю как доступ к базе будет. Проблема похоже со всеми принятыми.

Вообще пора убегать на 8.1.

Да пора, тока ошибки-то не было, наверное сбой какой-то был.

Тут посоветовали запустить пересчет суррогатных ключей (суппорт с параметром nusk+), что это изменит?

ну редко, но бывает, что индексы летят. Тыды еще поможет выгрузка в dbf грохание и загрузка - это тоже пересоздат индексы, при том только на одну таблу. Но все таки посмотрите что идет в sumultec.cex(надо = lschet.cex). Посмотрите по журналу когда туда вставляется запись и т.д. Да и persons.galdep смотрите. А в лиц.счет подразделение нормально попадает? Возможно дело связано с утверждением приказов при расчете зарплаты.

Идентичная проблема, только на платформе MS SQL Server 2000. Выдается ошибка что дублируется ключ в таблице SUMULTEC в поле NREC....как такое могло вообще произойти? Ошибка выдается тоже только по вновь принятым. Глюки начались после того как патчи новые поставили и в итоге теперь и со старыми такая же ерунда. Все выше описанное не помогает...

jornand, хочу уточнить, пока еще пробовал сам
Скрипт от edward_K не помогает?
Пересчет суррогатных ключей тоже делали?
7.12?

Версия 7.12. Пересчет суррогатных ключей еще не пробовали. А скрипт нам не помог, возможно у нас причина не в табельном номере.

jornand писал(а):Все выше описанное не помогает...

Вот проверять надо, прежде чем говорить.
На тестовой базе пересчет суррогатных ключей вроде как снял проблему. Скрипт не запускал. Да и проблема в данном случае не с табельными - у меня человек первый раз принимается, в таблице SUMULTEC нет такого табельного. Проблема явно привнесена патчем, скорее всего zarfix34, большинство наверное zarfix33 обошлись. Отмена патча проблемы не снимает.
Надо пробовать на рабочей.
Спасибо edward_K за ответы.