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

[nicko]

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

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

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

[Maxim Gorbunov]

Попробуйте запустить проверку данных (Администрирование - Периодические операции - SQL Администрирование; Таблицы - Проверить/Синхронизировать). Лучше запускайте сразу для всех таблиц.

[nicko]

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

[magnetica]

Здравствуйте, у меня возникла аналогичная ошибка при сохранении записей: "Невозможно сохранить запись. Вы пытаетесь оперировать с одной записью, но затрагивайте большее количество записей..." По данной проблеме нашла две темы на ахфоруме, однако нигде не было найдено решение проблемы в переписке. Темы довольно старые и я подумала, может, все же вам удалось побороть ошибку и узнать, с чем она была связана? Можете помочь советом?

[George Nordic]

Имхо, одинаковые имена у кодов - серий документов. Попробуйте переименовать.

С Уважением,
Георгий

[magnetica]

Спасибо за ответ, правда, вряд ли в моем случае это поможет. Дело в том, что подобной ошибки я добиваюсь несколько иным путем. К примеру, создала подряд несколько записей в справочнике "Счетов главной книги" (или в другой таблице), далее перемещаюсь между записями, обновляю то в одной поле, то в другой. Затем пытаюсь сохранить запись, и система радует таким сообщением....

[George Nordic]

Ключевое поле должно быть уникальным... Такая ошибка может быть, если Вы, допустим, забила два одинаковых номера счета (Допустим, 62.2.2 и 62.2.2). Если же она возникает просто при переходе по записям... ? То тогда-к программистам. Они должны подсказать, откуда возникает ошибка (посмотрев стек вызовов)

С Уважением,
Георгий

[magnetica]

С уникальностью ключевых полей понятно, конечно. Но изменяю я далеко не ключевые. :-( И это не плод наших трудов, поскольку ошибка возникает также и на чистом репозитарии SP3. Хорошо, посмотрим еще: есть ли в хотфиксах упоминания какие-либо данной ошибки... спасибо

[Alenka]

Добрый день.
Хочу возобновить обсуждение этой темы.
В некоторых случаях на разных таблицах при сохранении записи стало появляться сообщение "Вы пытаетесь оперировать с одной записью, но затрагивается большее количество записей. Проверьте индексы, запустите синхронизацию базы данных, или что-либо эквивалентное."
Аксапта работала 10 лет без подобных ошибок, а на днях разные пользователи при разных действиях на разных таблицах стали получать такое сообщение.

Ошибка появляется, как при двухуровневом подключении, так и при трехуровневом.

Синхронизация не помогает, Проверка/синхронизация никаких ошибок не выявила.

Может, кто-нибудь понял, в чем причина или как это можно поправить?

Ax 3.0, SP3, SQLServer.

[Wamr]

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

[Alenka]

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

[S.Kuskov]

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

[Ace of Database]

Цитата:

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

Спасибо за ответ, правда, вряд ли в моем случае это поможет. Дело в том, что подобной ошибки я добиваюсь несколько иным путем. К примеру, создала подряд несколько записей в справочнике "Счетов главной книги" (или в другой таблице), далее перемещаюсь между записями, обновляю то в одной поле, то в другой. Затем пытаюсь сохранить запись, и система радует таким сообщением....

Попробуйте в SQL Management Studio выполнить следующий запрос:
select count(*), RecId, DataAreaId from LEDGERTABLE group by DataAreaId, RecId having count(*) > 1

Запрос не должен возвратить ни одной записи. Вместо LEDGERTABLE можно использовать любую таблицу, на которой у вас выскакивает ошибка.

[Alenka]

2 S.Kuskov: Одна компания с двумя присоединенными виртуальными. Виртуальные подключены уже достаточно давно. Про dataareaId в индексах - не могу понять, как это можно проверить? Если только перестраивать индексы заново.
2 Ace of Database: Т.к. одна компания, то dataareaId в одной таблице одна, а RecId уникальны во всей базе (как я писала выше).

[Ace of Database]

Цитата:

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

2 S.Kuskov: Одна компания с двумя присоединенными виртуальными. Виртуальные подключены уже достаточно давно. Про dataareaId в индексах - не могу понять, как это можно проверить? Если только перестраивать индексы заново.
2 Ace of Database: Т.к. одна компания, то dataareaId в одной таблице одна, а RecId уникальны во всей базе (как я писала выше).

А вы мой запрос пробовали выполнить? Он проверит по факту оба ваших утверждения. По любому, вам придется лезть в SQL Management Studio, потому что там можно посмотреть свойства индексов на таблице. Ищите уникальный индекс, в котором есть поля dataAreaId и RecId. Индекс должен содержать только эти два поля.

[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. Сейчас их удалила. Но эти записи были старые, четырехлетней давности.

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

Цитата:

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

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

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

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

---------

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