Дублирование ключа

ПНР и сопровождение

Модераторы: m0p3e, edward_K, Модераторы

Ответить
Oweo
Местный житель
Сообщения: 355
Зарегистрирован: 29 мар 2005, 17:49

Дублирование ключа

Сообщение Oweo »

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

И, соответственно, при попытке зайти в кнопку "Размер годового дохода" (после з/п) выдается ошибка: Дублирование ключа. Таблица N16062
Платформа оракл. Что делать :sad:
Новые патчи удались на славу
s2176
Местный житель
Сообщения: 473
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Новосибирск

Сообщение s2176 »

Это происходит, если вы принимаете человека на тот же табельный номер, но в другое подразделение. Там проблемы с ключом возникают. Исправить можно суппортом поле CEX. Или сделайте в ЗП перевод сотрудника сначала в старое подразделение (из которого он увольнялся), а потом верните в новое.
Мы всех повторно принятых принимаем на новые табельные.
Кто сказал, что бесполезно биться головой об стену?!
Oweo
Местный житель
Сообщения: 355
Зарегистрирован: 29 мар 2005, 17:49

Сообщение Oweo »

s2176 писал(а):Это происходит, если вы принимаете человека на тот же табельный номер, но в другое подразделение.
Нет. Сотрудники принимаются на другой табельный номер. Кроме того, есть люди которых вообще нет в базе, ошибка по всем именно вновь принятым.
Ситуация просто похожа с той которая у вас возникла.
Исправить можно суппортом поле CEX.
Что все-таки нужно исправлять в таблице SUMULTEC и как?
Новые патчи удались на славу
edward_K
Заслуженный деятель интернет-сообщества
Сообщения: 5188
Зарегистрирован: 29 мар 2005, 17:49
Откуда: SPB galaxy spb

Сообщение edward_K »

#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)

возможны вариации(добавление фильтра по табельному например). Причина в том что изменения цеха в них не произошло.
Стандартный способ сделать сжатие бд - но оно не дает никаких протоколов - молча удаляет все кривые записи(даже если их еще можно спасти и они нужны).
Oweo
Местный житель
Сообщения: 355
Зарегистрирован: 29 мар 2005, 17:49

Сообщение Oweo »

edward_K писал(а):Стандартный способ сделать сжатие бд - но оно не дает никаких протоколов - молча удаляет все кривые записи(даже если их еще можно спасти и они нужны).
Запустил функцию
Расчет зарплаты - Сервисные функции - Сжатие базы данных
на тестовой базе. Еще есть варианты, чтоб без удаления лишнего?
возможны вариации(добавление фильтра по табельному например). Причина в том что изменения цеха в них не произошло.
Голова не соображает к вечеру. Вот есть человек, которого в базе нет, принимаем его на работу. Записи в таблице SUMULTEC с таким табельным нет. В какой момент изменения цеха не произошло? Что в таблице вообще можно посмотреть/удалить (будет делать сервисная функция), если нету там такого табельного.
Новые патчи удались на славу
edward_K
Заслуженный деятель интернет-сообщества
Сообщения: 5188
Зарегистрирован: 29 мар 2005, 17:49
Откуда: SPB galaxy spb

Сообщение edward_K »

запускайте мой лот и не партесь. сжатием лучше не пользоваться. Вообще возможно у вас не корректно установлена связь между структурными единицами и подразделениями. Persons.galdep проверте после приема - должно равняться lschet.cex. А тробла на всех принятых? Вообще пора убегать на 8.1.
Oweo
Местный житель
Сообщения: 355
Зарегистрирован: 29 мар 2005, 17:49

Сообщение Oweo »

edward_K писал(а):запускайте мой лот и не партесь.Persons.galdep проверте после приема - должно равняться lschet.cex. А тробла на всех принятых?
Запускать в модуле SQL - sql - ввод? Поле проверю как доступ к базе будет. Проблема похоже со всеми принятыми.
Вообще пора убегать на 8.1.
Да пора, тока ошибки-то не было, наверное сбой какой-то был.

Тут посоветовали запустить пересчет суррогатных ключей (суппорт с параметром nusk+), что это изменит?
Новые патчи удались на славу
edward_K
Заслуженный деятель интернет-сообщества
Сообщения: 5188
Зарегистрирован: 29 мар 2005, 17:49
Откуда: SPB galaxy spb

Сообщение edward_K »

ну редко, но бывает, что индексы летят. Тыды еще поможет выгрузка в dbf грохание и загрузка - это тоже пересоздат индексы, при том только на одну таблу. Но все таки посмотрите что идет в sumultec.cex(надо = lschet.cex). Посмотрите по журналу когда туда вставляется запись и т.д. Да и persons.galdep смотрите. А в лиц.счет подразделение нормально попадает? Возможно дело связано с утверждением приказов при расчете зарплаты.
jornand
Постоянный обитатель
Сообщения: 150
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Иркутск
Контактная информация:

Сообщение jornand »

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

Сообщение Oweo »

jornand, хочу уточнить, пока еще пробовал сам
Скрипт от edward_K не помогает?
Пересчет суррогатных ключей тоже делали?
7.12?
Новые патчи удались на славу
jornand
Постоянный обитатель
Сообщения: 150
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Иркутск
Контактная информация:

Сообщение jornand »

Версия 7.12. Пересчет суррогатных ключей еще не пробовали. А скрипт нам не помог, возможно у нас причина не в табельном номере.
Oweo
Местный житель
Сообщения: 355
Зарегистрирован: 29 мар 2005, 17:49

Сообщение Oweo »

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