AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 27.04.2004, 15:19   #1  
nicko is offline
nicko
Участник
 
229 / 11 (1) +
Регистрация: 19.02.2004
Адрес: Саров
? Редактирование записи
Подскажите что не так, вроде делаю все правильно.
В Сериях документов создаю серию для Личности, пример, ЛИЧ.
В модуле Управление персоналом в Параметрах на вкладке Номерные серии выбираю из списка серию документов ЛИЧ, система плюется такой вот ошибкой:

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

Пробовал запускать Синхронизацию и Обновление данных после синхронизации, не помогает.
?????????????
Старый 27.04.2004, 17:57   #2  
Maxim Gorbunov is offline
Maxim Gorbunov
Administrator
Соотечественники
Лучший по профессии 2009
 
2,483 / 645 (26) +++++++
Регистрация: 27.11.2001
Адрес: Dubai, UAE
Попробуйте запустить проверку данных (Администрирование - Периодические операции - SQL Администрирование; Таблицы - Проверить/Синхронизировать). Лучше запускайте сразу для всех таблиц.
__________________
Not registered yet? Register here!
Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me
Старый 05.05.2004, 10:50   #3  
nicko is offline
nicko
Участник
 
229 / 11 (1) +
Регистрация: 19.02.2004
Адрес: Саров
Пробовал запускать Синхронизацию таблиц, не помогает
Старый 25.01.2005, 13:11   #4  
magnetica is offline
magnetica
Участник
 
19 / 10 (1) +
Регистрация: 07.11.2003
Адрес: Kiev
:(
Здравствуйте, у меня возникла аналогичная ошибка при сохранении записей: "Невозможно сохранить запись. Вы пытаетесь оперировать с одной записью, но затрагивайте большее количество записей..." По данной проблеме нашла две темы на ахфоруме, однако нигде не было найдено решение проблемы в переписке. Темы довольно старые и я подумала, может, все же вам удалось побороть ошибку и узнать, с чем она была связана? Можете помочь советом?
Старый 25.01.2005, 13:14   #5  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Имхо, одинаковые имена у кодов - серий документов. Попробуйте переименовать.

С Уважением,
Георгий
Старый 25.01.2005, 13:26   #6  
magnetica is offline
magnetica
Участник
 
19 / 10 (1) +
Регистрация: 07.11.2003
Адрес: Kiev
Спасибо за ответ, правда, вряд ли в моем случае это поможет. Дело в том, что подобной ошибки я добиваюсь несколько иным путем. К примеру, создала подряд несколько записей в справочнике "Счетов главной книги" (или в другой таблице), далее перемещаюсь между записями, обновляю то в одной поле, то в другой. Затем пытаюсь сохранить запись, и система радует таким сообщением....
Старый 25.01.2005, 13:32   #7  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Ключевое поле должно быть уникальным... Такая ошибка может быть, если Вы, допустим, забила два одинаковых номера счета (Допустим, 62.2.2 и 62.2.2). Если же она возникает просто при переходе по записям... ? То тогда-к программистам. Они должны подсказать, откуда возникает ошибка (посмотрев стек вызовов)

С Уважением,
Георгий
Старый 25.01.2005, 13:42   #8  
magnetica is offline
magnetica
Участник
 
19 / 10 (1) +
Регистрация: 07.11.2003
Адрес: Kiev
С уникальностью ключевых полей понятно, конечно. Но изменяю я далеко не ключевые. :-( И это не плод наших трудов, поскольку ошибка возникает также и на чистом репозитарии SP3. Хорошо, посмотрим еще: есть ли в хотфиксах упоминания какие-либо данной ошибки... спасибо
Старый 31.01.2017, 16:59   #9  
Alenka is offline
Alenka
Участник
 
58 / 25 (1) +++
Регистрация: 19.04.2006
Добрый день.
Хочу возобновить обсуждение этой темы.
В некоторых случаях на разных таблицах при сохранении записи стало появляться сообщение "Вы пытаетесь оперировать с одной записью, но затрагивается большее количество записей. Проверьте индексы, запустите синхронизацию базы данных, или что-либо эквивалентное."
Аксапта работала 10 лет без подобных ошибок, а на днях разные пользователи при разных действиях на разных таблицах стали получать такое сообщение.

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

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

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

Ax 3.0, SP3, SQLServer.
Старый 31.01.2017, 20:53   #10  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Ax3.0... 10 лет
А проверьте-ка какие у вас RecId создаются
Старый 31.01.2017, 23:42   #11  
Alenka is offline
Alenka
Участник
 
58 / 25 (1) +++
Регистрация: 19.04.2006
С RecId у нас отдельная история.
Сейчас у нас отрицательные RecId, причем мы проходим отрицательные значения уже во второй раз. Т.е. мы прошли положительные, отрицательные, опять положительные и снова перешли на отрицательные. У нас организовано "хитрое" получение RecId из незанятых значений. И дублей у нас нет.
Это я к тому, что отрицательные значения не должны были повлиять на внезапное появление этой ошибки. Хотя у меня были сомнения насчет появившихся записей с дублирующимися RecId, которые теоретически могли вызвать подобную ошибку.
За это сообщение автора поблагодарили: mazzy (2).
Старый 01.02.2017, 07:32   #12  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга


вот здесь пишут что это ещё из-за глюков с DataAreaId может быть. Ошибка при сохраниении записи
Вы используете несколько компаний? Может у вас каким-то образом DataAreaId из какого-нибудь индекса выпала?
Старый 01.02.2017, 08:49   #13  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
870 / 637 (23) +++++++
Регистрация: 14.10.2004
Цитата:
Сообщение от magnetica Посмотреть сообщение
Спасибо за ответ, правда, вряд ли в моем случае это поможет. Дело в том, что подобной ошибки я добиваюсь несколько иным путем. К примеру, создала подряд несколько записей в справочнике "Счетов главной книги" (или в другой таблице), далее перемещаюсь между записями, обновляю то в одной поле, то в другой. Затем пытаюсь сохранить запись, и система радует таким сообщением....
Попробуйте в SQL Management Studio выполнить следующий запрос:
select count(*), RecId, DataAreaId from LEDGERTABLE group by DataAreaId, RecId having count(*) > 1

Запрос не должен возвратить ни одной записи. Вместо LEDGERTABLE можно использовать любую таблицу, на которой у вас выскакивает ошибка.
Старый 01.02.2017, 09:53   #14  
Alenka is offline
Alenka
Участник
 
58 / 25 (1) +++
Регистрация: 19.04.2006
2 S.Kuskov: Одна компания с двумя присоединенными виртуальными. Виртуальные подключены уже достаточно давно. Про dataareaId в индексах - не могу понять, как это можно проверить? Если только перестраивать индексы заново.
2 Ace of Database: Т.к. одна компания, то dataareaId в одной таблице одна, а RecId уникальны во всей базе (как я писала выше).
Старый 01.02.2017, 10:48   #15  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
870 / 637 (23) +++++++
Регистрация: 14.10.2004
Цитата:
Сообщение от Alenka Посмотреть сообщение
2 S.Kuskov: Одна компания с двумя присоединенными виртуальными. Виртуальные подключены уже достаточно давно. Про dataareaId в индексах - не могу понять, как это можно проверить? Если только перестраивать индексы заново.
2 Ace of Database: Т.к. одна компания, то dataareaId в одной таблице одна, а RecId уникальны во всей базе (как я писала выше).
А вы мой запрос пробовали выполнить? Он проверит по факту оба ваших утверждения. По любому, вам придется лезть в SQL Management Studio, потому что там можно посмотреть свойства индексов на таблице. Ищите уникальный индекс, в котором есть поля dataAreaId и RecId. Индекс должен содержать только эти два поля.
Миниатюры
Нажмите на изображение для увеличения
Название: Безымянный.jpg
Просмотров: 449
Размер:	234.1 Кб
ID:	11171  
Старый 01.02.2017, 10:52   #16  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
870 / 637 (23) +++++++
Регистрация: 14.10.2004
И еще одно, если у вас таблица LedgerTable входит в табличную коллекцию,то проверьте что в базе данных для нее есть только те записи, у которых DataAreaId равна коду виртуальной компании. Не должно быть записией с DataAreaId, равными кодам обычных компаний, которые входят в виртуальные.
Например, если виртуальная компания называется vir, а в нее входит обычная компания dat и таблица LedgerTable входит в табличную коллекцию, привязанную к данной виртуальной компании, то
1) Это запрос не должен вернуть ни одной записи
select * from LedgerTable where DataAreaId = 'dat'
2) Это запрос вернет те записи, которые видны в Аксапте:
select * from LedgerTable where DataAreaId = 'vir'

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

Последний раз редактировалось Ace of Database; 01.02.2017 в 11:00.
Старый 01.02.2017, 11:00   #17  
Alenka is offline
Alenka
Участник
 
58 / 25 (1) +++
Регистрация: 19.04.2006
Во-первых, спасибо, что вникаете в проблему.
Во-вторых, по пунктам:
1. Нет, я не пробовала выполнить ваш запрос, т.к. утверждение про отсутствие дублей RecId в базе - не голословное утверждение, а проверенное.
2. У нас нет проблем с таблицей LedgerTable. Проблемы возникали как со стандартными таблицами, типа PurchTable или SalesLine, так и с созданными нами таблицами. В табличные коллекции, соответствующие виртуальным компаниям, входят созданные нами таблицы, с которыми проблем пока не возникало. Про dataareaId в таблицах - проверю, результат напишу попозже.
Старый 01.02.2017, 11:04   #18  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
870 / 637 (23) +++++++
Регистрация: 14.10.2004
И еще по поводу быстрой проверки виртуальной компании. Проверку можно упростить.
Этот запрос не должен вернуть ни одной записи:
select * from LedgerTable where DataAreaId <> 'vir'
Старый 01.02.2017, 12:05   #19  
Alenka is offline
Alenka
Участник
 
58 / 25 (1) +++
Регистрация: 19.04.2006
В обычных таблицах проблем с dataareaId нет. В паре таблиц из табличной коллекции, соответствующей виртуальной компании, были записи с неправильным dataareaId. Сейчас их удалила. Но эти записи были старые, четырехлетней давности.
Старый 01.02.2017, 13:27   #20  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Alenka Посмотреть сообщение
С RecId у нас отдельная история.
Сейчас у нас отрицательные RecId, причем мы проходим отрицательные значения уже во второй раз. Т.е. мы прошли положительные, отрицательные, опять положительные и снова перешли на отрицательные. У нас организовано "хитрое" получение RecId из незанятых значений. И дублей у нас нет.
Как предположение. Возможно, Ваш генератор RecId либо сформировал несколько одинаковых значений, либо сформировал RecId, который уже есть для существующей записи. Имею в виду, процесс создания новых записей до их сохранения. Т.е. реальных дублей в базе нет. Ошибка именно на этапе сохранения

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

---------

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

Последний раз редактировалось Владимир Максимов; 01.02.2017 в 13:32.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
AX4: Кнопка "Сценарий" в паспорте записи Den Ram DAX: Функционал 2 19.04.2007 13:53
ALEG: Доступны записи тренингов по Microsoft Dynamics NAV Blog bot DAX Blogs 0 21.03.2007 15:00
Вытащить записи из InventSum ... Rimantas DAX: Программирование 23 07.11.2006 14:47
Как решить проблему с правами на вновь создаваемые записи таблицы. AY DAX: Прочие вопросы 4 02.10.2003 12:44
Автоматическое увеличение значения поля при создании новой записи. sguryev DAX: Программирование 3 06.02.2003 14:00
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:09.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.