Редактирование записи

[nicko]

Подскажите что не так, вроде делаю все правильно.
В Сериях документов создаю серию для Личности, пример, ЛИЧ.
В модуле Управление персоналом в Параметрах на вкладке Номерные серии выбираю из списка серию документов ЛИЧ, система плюется такой вот ошибкой:

"Невозможно отредактировать запись в 'Ссылки на серии' ('NumberSequenceReference'). Вы пытаетесь оперировать с одной записью, но затрагивается большее количество записей, проверьте индексы, запустите синхронизацию, либо что-то эквивалентное"

Пробовал запускать Синхронизацию и Обновление данных после синхронизации, не помогает.
?????????????

[Wamr]

Ax3.0... 10 лет
А проверьте-ка какие у вас RecId создаются

[Alenka]

С RecId у нас отдельная история.
Сейчас у нас отрицательные RecId, причем мы проходим отрицательные значения уже во второй раз. Т.е. мы прошли положительные, отрицательные, опять положительные и снова перешли на отрицательные. У нас организовано "хитрое" получение RecId из незанятых значений. И дублей у нас нет.
Это я к тому, что отрицательные значения не должны были повлиять на внезапное появление этой ошибки. Хотя у меня были сомнения насчет появившихся записей с дублирующимися RecId, которые теоретически могли вызвать подобную ошибку.

[Владимир Максимов]

Цитата:

Сообщение от Alenka

С RecId у нас отдельная история.
Сейчас у нас отрицательные RecId, причем мы проходим отрицательные значения уже во второй раз. Т.е. мы прошли положительные, отрицательные, опять положительные и снова перешли на отрицательные. У нас организовано "хитрое" получение RecId из незанятых значений. И дублей у нас нет.

Как предположение. Возможно, Ваш генератор RecId либо сформировал несколько одинаковых значений, либо сформировал RecId, который уже есть для существующей записи. Имею в виду, процесс создания новых записей до их сохранения. Т.е. реальных дублей в базе нет. Ошибка именно на этапе сохранения

В идеале, надо бы поймать момент, когда происходит ошибка и посмотреть RecId изменяемых записей, сравнив с RecId уже существующих

---------

Кстати, если при повторной попытке сохранения тех же самых данных (или при нескольких повторных попытках) все-так сохранение выполняется, значит проблема точно в генераторе RecId. Точнее, в тех полях, содержимое которых формируется автоматически. Причем при каждой новой попытке сохранения формируются новые значения. Как правило, это характерно только для RecId, но, может быть, у Вас реализовано еще что-то свое.

[Alenka]

Я нашла причину. И она оказалась вовсе не в базе данных, а в коде.
Был добавлен вызов SQL запроса, в котором в начале отключался вывод кол-во полученных строк результата (set nocount on), а в конце забыли его включить (set nocount off). После выполнения запроса любой следующий update любой таблицы выдает ошибку "Вы пытаетесь оперировать с одной записью, но затрагивается большее количество записей. Проверьте индексы, запустите синхронизацию базы данных, или что-либо эквивалентное."

Например, выполнение вот такого простейшего job'a приведет к ошибке для следующего update'a любой записи на любой форме.

static void probaSetNocountOff(Args _args)
{
    UserConnection          connection      = new UserConnection();
    Statement               stmt            = connection.createStatement();
    ResultSet               rSet;
    str                     query_;
    ;
    query_ = "set nocount on"
           + "\n"
           + "select top 1 ItemId "
           + "from InventTable (nolock) "
           + "where dataareaID = '" + curext() + "'"
           + "\n"
//         + "set nocount off"
           ;

    rSet = stmt.executeQuery(query_);

    while (rSet.next())
    {
        info(rset.getString(1));
    }
}

Если добавить set nocount off, то ошибки не будет.

В общем, сами создаем себе проблемы.

Всем спасибо за ответы.

[S.Kuskov]

вот здесь пишут что это ещё из-за глюков с DataAreaId может быть. Ошибка при сохраниении записи
Вы используете несколько компаний? Может у вас каким-то образом DataAreaId из какого-нибудь индекса выпала?

[Ace of Database]

И еще одно, если у вас таблица LedgerTable входит в табличную коллекцию,то проверьте что в базе данных для нее есть только те записи, у которых DataAreaId равна коду виртуальной компании. Не должно быть записией с DataAreaId, равными кодам обычных компаний, которые входят в виртуальные.
Например, если виртуальная компания называется vir, а в нее входит обычная компания dat и таблица LedgerTable входит в табличную коллекцию, привязанную к данной виртуальной компании, то
1) Это запрос не должен вернуть ни одной записи
select * from LedgerTable where DataAreaId = 'dat'
2) Это запрос вернет те записи, которые видны в Аксапте:
select * from LedgerTable where DataAreaId = 'vir'

Это надо делать в SQL Management Studio

[Alenka]

Во-первых, спасибо, что вникаете в проблему.
Во-вторых, по пунктам:
1. Нет, я не пробовала выполнить ваш запрос, т.к. утверждение про отсутствие дублей RecId в базе - не голословное утверждение, а проверенное.
2. У нас нет проблем с таблицей LedgerTable. Проблемы возникали как со стандартными таблицами, типа PurchTable или SalesLine, так и с созданными нами таблицами. В табличные коллекции, соответствующие виртуальным компаниям, входят созданные нами таблицы, с которыми проблем пока не возникало. Про dataareaId в таблицах - проверю, результат напишу попозже.

[Ace of Database]

И еще по поводу быстрой проверки виртуальной компании. Проверку можно упростить.
Этот запрос не должен вернуть ни одной записи:
select * from LedgerTable where DataAreaId <> 'vir'

[Alenka]

В обычных таблицах проблем с dataareaId нет. В паре таблиц из табличной коллекции, соответствующей виртуальной компании, были записи с неправильным dataareaId. Сейчас их удалила. Но эти записи были старые, четырехлетней давности.