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

Уже ошибка тянется несколько месяцев. :-[Началась еще в 573. Раньше у нас работал с входящими документами и платежками тока один бухгалтер. С того года пришла еще одна. Когда одна бухша работает в ФРО во входящих документах, платежных поручениях или бухгалтерской справке и привязывает ТХО, то другая при этом, работающая тоже в ФРО в каком -нить из этих документов и тоже хочет привязать ТХО, то одной их них выдает ошибку №5 - дублирование значение при уникальном ключе. В таблице PLpor повторяется значение поля NRec. В результате проводки не формируются и документ удаляется ( у одной бухши) Если она документ создает заново и начинает прявязывать ТХО то ошибка может появиться у другой. Вот такая вот бяда. Выхода не видать. Принимаются любые предложения по решению. Очень надо. Помогите!!!!! ??? ???
З.Ы. Другая ошибка (как мне кажется они похожи) бухши тоже привязывают ТХО и если 2 пааллельно хотят ето сделать то им выдает "Ошибка создания проводки" и в итоге приходится заново все делать. Забодались наши бухши уже. :`( Помогите люди добрые советом.

Проблема началась с использованием новой системой генерации nrec. Для части таблиц этот алглритм не поддерживается. Но тагже на это влияет наличие как 7 так и 2000 клиентов. Итак: поставь везде 2000 клиента и добавь в конфиг таблы которые не поддерживают новой системой генерации nrec. Список скорее всего не полный но если не поможет могу рассказать методику его формирования. RandomSurrKeys=On RandomSurrKeysExcludeList=KODOF;X$ACTIVEUSERS;EVENTS;SPDOCNAL;BASEFIN;SPSOPR;SOPRHOZ;OBOROT;PLPOR;BANKDOCF;VEDDEPONIR;HOZOBOR;
PS: Это решение я рассказал в тех поддержке. Странно если они о этом не говорят. Хлтя возможно проблема и в другом..... Если что пиши. ;D

Антон! К сожалению ошибка не снялась,
а даже наоборот, стала проявляться не только у бухгалтеров, но и у диспетчеров, причем помимо 5 ошибки еще начало ругаться на ошибку вставки записи в spsopr. Убрала запись RandomSurrKeysExcludeList из startup.cfg, все вернулось на прежнее место. Диспетчера стали работать в нормальном режиме, а бухгалтерам сыпаться ошибки, причем №5 тока у бухш работающих в ФРО, а 4 ошибка или "ошибка вставки прводки" у многих бухгалтеров. Им приходится по 2-4 раза перевыбирать одну и ту же ТХО пока она не привяжется. А это не вызывает у них бурной радости. :-[
Вопрос: Ё МОЁ ЧТО ЖЕ ДЕЛАТЬ?
Вообще я заметила что раньше таких ошибок не было. 5 ошибка началась в том году еще на 573 когда 2 бухш стало работать в ФРО. А ошибка вставки проводки активно полезла с этого года, а с переходом на 582 это происходит непрерывно. Я не грешу на 582, может как-то криво первасив работает? Или руки? Что бы такого еще сделать?
Решила попробовать полечить их. Может поможет? Хотя сомневаюсь. :-[ ???

День добрый !
С Галактикой я недавно работаю а вот с
Betrive а потом и Первасив уже давно
Для начала я бы сделал следующее
1. Определил таблицу или круг таблиц на которых выскакивает ошибка.
2. Убедился что таблици исправны т.е.
средствами первасива потестировал а еще лучше пересоздал их.
(возможно ошибка из за сбоя индекса в таблице)

3. если не помогло ? Думаем над логикой
Галактики. Почему она пытаеся создать ключ
который уже есть ? В принципе тут тоже есть варианты .....

Кстати может кто поможет мне по ж/д тарифу ...? см. вопрос ниже ...

Вряд ли поможет, но хуже не будет точно.
Попробуй удалить файл D_Dict\Surrkeys.adf
Там хранятся последние значения для суррогатных ключей, так что может быть там глюк.

А какая версия Pervasive?Появляться ошибка начала не после установки новой версии?Ошибка выскакивает на всех рабочих станциях или только на определенных?Если на определенных, то чем они отличаются от других?Попытайся сменить раб. станцию для того бухгалтера, у которого стабильно проявляется ошибка.

Круг таблиц определен: soprhoz, plpor
Полечила их средствами первасива - не помогло. .`) :-[
По-поводу пересоздания - с этого года таблицы были чистыми - нулевыми, т.к. год начали с нуля, но ошибка все одно была. ???
Рабочие станции все подвержены етой ошибке - не зависит от этого. От имени тоже.
По-поводу первасива - ошибка пошла ( как мне кажется и помнится) именно с момента перехода на первасив 2000 с бетрива 6.15. По крайней мере примерно в то время. Но может и не связано это. Ненаю. :-[
Попробовала удалить D-Dict - создали 2-3 документа ошибка не проявилась ( может мало попробовали а может получилось) ???
Короче решила в рабочей версии удалить Surrkeys.adf
завтра будемпроверять в рабочем режиме. ;D ???

Удаление Surrkeys.adf не помогло. >:(
Буду дальше мучаться. Что за е мое.

А вот еще более актуальная ьрабла наклюнулась я писала выше о ней. Периодически ( может несколько раз в час, а может 1 раз в день, видимо из-за того что кто-то параллельно работает) у бухов при привязке ТХО возникает "Ошибка вставки проводки". Забодалися. Может из этой же серии трабла а может и нет. Т.к. когда одна бухша привязывает трабла кажись не возникает. Т.е. видимо ошибка из той же оперы не дает параллельно вставлять записи в таблицу soprhoz или еще какую.
Вот поделилась наболевшим..............

Недавно вышел патч по похожей проблеме.Может и вам поможет.

А что за патч?

Selena

Народ!!! Чем кончилась эта история?!?! Как лечить проблему?
Аналогичная проблема возникла при переходе с первасива 7-го на 8-й. Если у клиента стоит 7-й первасив, проблем не наблюдается. Если 8-й - валятся ошибки вставки новых проводок и начинается "путаница" записей при использовании встроенных процедур экспорта документов. В остальном проблем нет. Конечно можно держать сервер под восьмеркой. а клиентов ставить 7-х, но ведь это не нормально!!! Так не должно быть? Может дело в настройках первасива или не полной совместимости версий первасива?
При работе с в-м первасивом мы использует БД формата 7-1 версии, что и указали в настройках. Может в этом дело? Может нужно перевести базы в 8-ку?

в 8.10 появилась настройка, запрещающая двум юзерам редактировать одну и ту же платежку одновременно. При входе в платеж юзером, он блокируется.

У нас версия 5,74
Речь не идет об одновременном редактировании одного документа. Речь идет об одновременном формировании проводок по РАЗНЫМ документам. Уверен, что проблема вызвана способом генерации нрека. Судя по всему функция GetNextNrec в разных версия первасива срабатывает по-разному.
Ведь именно в алгоритме формирования проводки сначала получается нрек, а затем производится попытка вставить запись в таблицу с таким нреком.

С версией 5.74 я даже не знаю что вам предложить сделать Она года с 2002 с поддержки снята...