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

Доброго времени суток!
Ошибка проявляется только на вновь принятых работников. Если после создании нового лицевого счета перейти в "Размер годового дохода=>До расчета зарплаты", выскакивает ошибка:
"Ошибка 5
Дублированное значение при уникальном ключе
в таблице 'T$SUMUPTEC'.
Уникальный индекс 'T$SUMUPTEC1'.
Поле F$NREC Comp(8):0x1c00000000000100 таблица №16065".
При расчёте заработной платы этого сотрудника в протоколе пишется:
"Ошибка 5 при работе с таблицей SUMUPSOC....".
После перехода на следующий период, ошибка на этом сотруднике не проявляется и зарплата рассчитывается без ошибок. Такая ситуация повторяется с каждым новым лицевым счетом.
gal810, mssql2005

таже хрень на таблица №16066". помогло удаление всех записий перед формированием!

то есть перед расчетом просто очистить таблицу надо? остальные лицевые счета не пострадают?

и еще
Из MS70DRV_DLL_54160.txt:
Код:

№4
* ПРОБЛЕМА В ПИР: 103.4054
* ПЕРВОЕ РЕШЕНИЕ: NEW
* КРАТКОЕ ОПИСАНИЕ: Ошибки при переходе в ЗП на другой отчетный период. MsSQL
* ПРОЕКТ: Поддержка различных платформ баз данных
* ДЕТАЛИЗАЦИЯ: MS SQL
# ЧТО ИЗМЕНЕНО: Журнализация включена по всем таблицам >1000
Протект включен.
Захожу в заработную плату
под пользователем _не_админом_.
- отчетный месяц 01.2006
Запускаю переход
Расчет зарплаты - Переход к новому периоду
в процессе перехода получаю лог ЗП см. вложение1
в ms70drv.log тот же список таблиц. +
11.02.2009 11:59:30 [GAL810MASTER#LEONID#1]:
INSERT INTO
V$SUMUPSOC("F$NREC","F$ATL_LASTDATE","F$ATL_LASTTIME","F$ATL_LASTUSER","F$ATL_OR
IGINOFFICE","F$
....
42000: [Microsoft][ODBC SQL Server Driver][SQL Server]INSERT permission denied
on object 'V$SUMUPSOC', database 'Gal810Master', owner 'dbo'.
полный лог во вложении 2
В итоге SUMUPSOC - пустая!
Контроль SUMUPSOC (сервисная функция в ЗП) под тем же
пользователем работает корректно.

# КАК ИЗМЕНЕНО: Доработан код раздачи прав на соответствующие объекты.

# ИНСТРУКЦИЯ ПО НАСТРОЙКЕ: После установки обновления перед запуском
приложения
необходимо принудительно пересчитать права
пользователей на таблицы с помощью утилиты Саппорт. При
этом значение конфигурационного параметра
SQLDriver.ForceRights должно быть установлено в "On".

* * *
№5
* ПРОБЛЕМА В ПИР: 104.18742
* ПЕРВОЕ РЕШЕНИЕ: NEW
* КРАТКОЕ ОПИСАНИЕ: Сбои при закрытии отчетного периода
* ПРОЕКТ: Зарплата
* ДЕТАЛИЗАЦИЯ: Переход к новому периоду
# ЧТО ИЗМЕНЕНО: При включенной галочке "быстро удалять данные текущего периода
(без журнализации)"
на платформе MS SQL (тестировалось на MS SQL 2000 SP4, сборка экзешников на
атлантисе 5.3.24) в протокол выводятся сообщения:
[!] Предупреждение !!! Не очистился справочник ROUTING
[!] Предупреждение !!! Не очистился справочник RASORD
[!] Предупреждение !!! Не очистился справочник CHILDONE
[!] Предупреждение !!! Не очистился справочник PEREVODTEK
[!] Предупреждение !!! Не очистился справочник SUMUPSOC
[!] Предупреждение !!! Не очистился справочник SUMUPPRO
[!] Предупреждение !!! Не очистился справочник SUMUPBUD
[!] Предупреждение !!! Не очистился справочник SUMUPTEC
[!] Предупреждение !!! Не очистился справочник DOPNAP
[!] Предупреждение !!! Не очистился справочник DOPNAP2
[!] Предупреждение !!! Не очистился справочник SYS_UDER
[!] Предупреждение !!! Не очистился справочник "Информация о работнике за
текущий месяц"
После чего переход вроде бы нормально завершается. Но на самом деле
после такого перехода расчет зарплаты (в частности, налогов) выполняется
неверно.
Штатных средств для возращения БД в корректное состояние не предусмотрено.
Хотелось бы узнать, из за чего могут возникать такие ошибки и как с ними
бороться.
Считаю, что такие сообщения должны быть не предупреждениями, а ошибками.
При возникновении первой ошибки переход должен прерываться, а отчетный период
в этом случае изменяться не должен. В этом случае возможно будет предпринять
необходимые действия для исправления ситуации и выполнить переход повторно.
Для того, чтобы дать возможность решить проблему вручную, предлагаю
перед очисткой данных таблиц проверять, есть ли в них записи и,
запускать очистку только в случае, если записи есть. Это позволит при
необходимости очистить данные таблицы вручную.

# КАК ИЗМЕНЕНО: Причина сбоя в работе метода TruncateTable устранена.

Это уже все испытано, проблема с переходом была такая же, ее решили обновлением, а вот в данной ситуации с расчетом ЗП обновление не помогло...

что касательно таблица №16066" мы просто ее очистили
проблемой занимался не я но просто знаю результат что потом все отработало

1. поищите на форуме - уже вроде кто-то жаловался
2. раньше была проблема с полем cex (индекс по Tabn уникальный, а поиск искался по tabn+cex). И корни были в том, что поле persons.galdep не заполнилось. Посмотрите по челу запись на эти поля.

скорей всего проблема с сурогатными ключами. необходимо запустить атл приложение c корректировкой суррогатных ключей.
Где то на форме уже было типа galnet.exe /nusk+

Ged
Спасибо! galnet.exe /nusk+ помогло!