|
12.12.2006, 11:57 | #1 |
Участник
|
Привет всем!
При учете нескольких строк финжурнала случайным образом появляется сообщение такого вида - "ФинКнига Операций уже существует .... Операция Но=****" (см рис) и учет отваливается, оставив в базе следы - то есть часть строк учитывается [attachment=545:attachment] Проблема похоже в кодюните 12 что-то неправильное с изменением переменной NextEntryNo (она подставляется в поле "Entry No" и при инициализации считывается максимальный "Entry No" из таблицы + 1 ) или ( идея #2) - при одновременном учете от нескольких пользователей не срабатывает блокировка таблицы, и в таблицу заносятся записи от другого пользователя с номером, который планирует использовать текущий сеанс в качестве "Entry No" для записи в таблицу Может кто сталкивался с таким или может подсказать идеи, где копать? |
|
12.12.2006, 12:18 | #2 |
Участник
|
Круто!
Копать в следах "кастомизации". |
|
12.12.2006, 13:00 | #3 |
Участник
|
Возможные причины:
1. копались в 12 КЮ; 2. неправильно что-то исправили в базе - поясню: насколько я помню, номер операции вычисляется следующим образом - фильтруется 17-я таблица по номеру транзакции, берется последняя запись и к номеру операции прибавляется один. Т.е. номер транзакции последний, а номер записи при этом не последний. 3. то, что в базе остаются проводки указывает на то, что явно правили 12 КЮ, и в результате правок появились дополнительные коммиты, я бы начал от туда. |
|
12.12.2006, 13:15 | #4 |
Участник
|
А вы уверены, что такой номер операции у вас в базе существует. Есть большие подозрения, что его и в базе то нет.
|
|
12.12.2006, 14:08 | #5 |
Участник
|
Fordewind, как нет если такую ошибку дает именно INSERT?!
|
|
12.12.2006, 14:24 | #6 |
Участник
|
Помню была похожая ситуация. Такая же ошибка. В чем там именно дело было не помню
Но четко помню, что когда смотрел в базу, то такой операции там не было! Нумерация до него еще не дошла операций эдак на 100. (Версия была 3.6) Кстати, как версия: Возможно, где-то баг при вставке во временную таблицу. в КЮ 12 инетерсным образом гоняются NextEntryNo +/- 1. Может где-то налажали |
|
13.12.2006, 08:57 | #7 |
Участник
|
Ну так значит оно в рамках одной транзакции писало в один и тот же номер операции или и правда во временную. Вобще я склоняюсь к варианту, что если ничего криминального в коде нет, там что-то криво поудаляли из таблиц.
|
|
13.12.2006, 10:53 | #8 |
Участник
|
У нас вариант кривого удаления отпадал. Ничего руками не удаляли.
|
|
12.12.2006, 15:28 | #9 |
Гость
|
аналогичная фишка была. учет операций клиента с применением рублей к другой валюте.
есть подозрение, что глюк может проявляться и в других ситуациях. попытайтесь отловить ситуацию. |
|
12.12.2006, 16:44 | #10 |
Участник
|
Если речь идет о какой-то тестовой базе, то возможно удаляли "руками" G/L Entry и не почитстили G/L Register.
|
|
12.12.2006, 18:26 | #11 |
Moderator
|
Какая версия Навижина?
Эта ошибка была в 2.60 и связана, если память не изменяет, с учетом НДС... Лечилась добавлением 1-й строчки в 12 кодеюнит. |
|
12.12.2006, 19:04 | #12 |
Участник
|
Спасибо всем за идеи!
>> Копать в следах "кастомизации". еще раз просмотрели кастомизацию,ничего особо криминального не видно >>> 2. неправильно что-то исправили в базе - поясню: насколько я >>> помню, номер операции вычисляется следующим образом - >>> фильтруется 17-я таблица по номеру транзакции, берется >>> последняя запись и к номеру операции прибавляется один. >>> Т.е. номер транзакции последний, а номер записи при этом не >>> последний. там явно ведется поиск по фильтру по Entry No и ищется последняя запись >> Fordewind, как нет если такую ошибку дает именно INSERT?! точно, это же именно в INSERT из-за наличия записи с таким же значением первичного ключа >> Какая версия Навижина? >> Лечилась добавлением 1-й строчки в 12 кодеюнит 3.70, и какой строчки? |
|
13.12.2006, 01:34 | #13 |
Участник
|
|
|
13.12.2006, 15:23 | #14 |
Участник
|
Цитата:
не может. |
|
14.12.2006, 16:39 | #15 |
Участник
|
То, что журнал учитывается частично, как раз ничего криминального нет. Это COMMITы из 13 кодеюнита срабатывают, если несколько документов сразу учитываются, с разными номерами или датами.
|
|
12.12.2006, 19:12 | #16 |
Moderator
|
В 3.70 этой ошибки уже не было, так что ищи дебагером.
В 2.60 не присваивался номер новой операции при вставке суммированного НДС. |
|
13.12.2006, 13:34 | #17 |
Участник
|
Значит попахивает криминалом
|
|
14.12.2006, 17:05 | #18 |
Участник
|
Дополнение к предыдущему. (что-то сообщение не редактируется)
Переменная NextEntryNo инкрементируется только в одном месте, в функции InsertGLEntry. соотвественно и ошибка может возникнуть, только если при кастомизации строку пытаются вставить в tab17 без помощи этой функции. Ручная правка в принципе не может привести к такой ошибке. Параллельный учет тоже - в функции InitCodeunit сразу идет LOCKTABLE на tab17. |
|