Проблема стара, но что-то решения на форуме не нахожу.
После расчет зп по вновь принятым выходит ошибка: Ошибка при работе с таблицей "Размер годового дохода после расчета зарплаты(тек)"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;
возможны вариации(добавление фильтра по табельному например). Причина в том что изменения цеха в них не произошло.
Стандартный способ сделать сжатие бд - но оно не дает никаких протоколов - молча удаляет все кривые записи(даже если их еще можно спасти и они нужны).
edward_K писал(а):Стандартный способ сделать сжатие бд - но оно не дает никаких протоколов - молча удаляет все кривые записи(даже если их еще можно спасти и они нужны).
Запустил функцию Расчет зарплаты - Сервисные функции - Сжатие базы данных
на тестовой базе. Еще есть варианты, чтоб без удаления лишнего?
возможны вариации(добавление фильтра по табельному например). Причина в том что изменения цеха в них не произошло.
Голова не соображает к вечеру. Вот есть человек, которого в базе нет, принимаем его на работу. Записи в таблице SUMULTEC с таким табельным нет. В какой момент изменения цеха не произошло? Что в таблице вообще можно посмотреть/удалить (будет делать сервисная функция), если нету там такого табельного.
запускайте мой лот и не партесь. сжатием лучше не пользоваться. Вообще возможно у вас не корректно установлена связь между структурными единицами и подразделениями. Persons.galdep проверте после приема - должно равняться lschet.cex. А тробла на всех принятых? Вообще пора убегать на 8.1.
ну редко, но бывает, что индексы летят. Тыды еще поможет выгрузка в dbf грохание и загрузка - это тоже пересоздат индексы, при том только на одну таблу. Но все таки посмотрите что идет в sumultec.cex(надо = lschet.cex). Посмотрите по журналу когда туда вставляется запись и т.д. Да и persons.galdep смотрите. А в лиц.счет подразделение нормально попадает? Возможно дело связано с утверждением приказов при расчете зарплаты.
Идентичная проблема, только на платформе MS SQL Server 2000. Выдается ошибка что дублируется ключ в таблице SUMULTEC в поле NREC....как такое могло вообще произойти? Ошибка выдается тоже только по вновь принятым. Глюки начались после того как патчи новые поставили и в итоге теперь и со старыми такая же ерунда. Все выше описанное не помогает...
jornand писал(а):Все выше описанное не помогает...
Вот проверять надо, прежде чем говорить.
На тестовой базе пересчет суррогатных ключей вроде как снял проблему. Скрипт не запускал. Да и проблема в данном случае не с табельными - у меня человек первый раз принимается, в таблице SUMULTEC нет такого табельного. Проблема явно привнесена патчем, скорее всего zarfix34, большинство наверное zarfix33 обошлись. Отмена патча проблемы не снимает.
Надо пробовать на рабочей.
Спасибо edward_K за ответы.
