![]() |
#1 |
Участник
|
Ошибки при синхронизации
Добрый вечер.
Недавно перенес очередной проект на рабочее приложении, в проекте несколько таблиц несколько классом... Так вот после переноса запустил компиляцию проекта и синхронизацию таблиц проекта и при синхронизации получил вот такое сообщение. Сообщение пропало только после того как я снял со всех таблиц перенесенного проекта индексы, но буквально сегодня прилетела новая проблема с этим проектом и таблицами из него. Система выдала вот такую прелесть [Microsoft][SQL Server Native Client 10.0][SQL Server]Index 'I_51205RECID' on table 'WMCOUNTADDFROMATSDTABLE' (specified in the FROM clause) does not exist и перестала работать. Пользователь вышел из системы повторно зашел и пока ошибка не повторялась. Может кто подскажет что это может быть и в каком направлении рыть. Из действий которые уже выполняли чтобы решить данную проблему останавливали AOS, повторно переносил проект да и все наверно. Ax 3.0 |
|
![]() |
#2 |
Участник
|
Похоже, что где-то в коде запроса указан hint для использования индекса по recid таблицы. После того как вы отключили индексы, код, который их использует будет выдавать ошибки.
Нужно или включить индексы и сделать ревизию кода на необходимость использования hintов при запросе к таблицам.
__________________
Ален ноби, ностра алис. Что означает - если один человек построил, другой завсегда разобрать может. |
|
![]() |
#3 |
Участник
|
проблема в том что hint - овых индексов там нет, а проблема проявилась после переноса проекта и говорила, что не может внести изменения в индекс (не на стороне Ax а на стороне Sql сервера alter index....) и исчезла после того как я снес все индексы на таблицах проекта. А теперь на сколько я понял система сама сделала индекс по RecId и не может что - то с ним сделать, что и приводит к ошибке.
|
|
![]() |
#4 |
Участник
|
Посмотрите есть ли у Вас записи с одинаковым RecId в этой проблемной таблице? В AX2009, например (на скриншоте видно что у вас или 3.0 или 4.0 - поэтому не знаю сейчас как там), не создать даже не уникальный индекс на поле RecId, если есть 2 записи с одинаковым RecId. Решив проблему с такими записями, решалась и проблема создания индекса!
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
![]() |
#5 |
Участник
|
Индекс может отсутствовать по 2 причинам
1. Физически нет на стороне SQL, но в Axapta он есть 2. Имя индекса, сформированное в Axapta, не соответствует имени индекса в SQL 1. Физически нет на стороне SQL, но в Axapta он есть Если не рассматривать вариант, когда удалили на стороне SQL вручную, то это то, что уже сказал Pustik Если индекс имеет свойство AllowDuplicates = No, то в таблице не должно быть дублей по полям этого индекса. Иначе он не сможет быть создан в SQL, хотя в Axapta будет присутствовать. Например, индекс по RecId имеет такое свойство Т.е. как раз и получим описанную ситуацию. В среде Axapta индекс есть, но в SQL он так и не был создан 2. Имя индекса, сформированное в Axapta, не соответствует имени индекса в SQL Имя индекса SQL формируется так "I_" + "id таблицы" + "Имя индекса в Axapta" В среде Axapta индекс ищется по его имени собственно в Axapta ![]() При обновлении таблиц их id не менялся? Или может Axapta при каких-то условиях "теряет" корректное значение id-таблиц?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Мышелов Федор (1). |
![]() |
#6 |
Участник
|
Действительно, на одном приложении Id элемента 51210 на другом 51207, это порождает следующий вопрос, а точнее два. Как такое могло случится, а самое главное как это лечить
![]() |
|
![]() |
#7 |
Banned
|
Это у вас Axapta 3.0 и Windows XP? Вот это да!!
В древних версиях системы была форма SQL Administration или типа того, и какая-то кнопка справа для лечения и перестройки индексов? Вот, нашел в чуть менее раритетной системе: Кажется, лет десять назад было еще принято удалять строки в SQLDICTIONARY и пересинхронизировать. Последний раз редактировалось EVGL; 17.12.2020 в 18:23. |
|
![]() |
#8 |
Участник
|
Цитата:
Соответственно, если галку устанавливать, то новый объект будет создан с переданным id (если это возможно). Если галку не ставить, то id нового объекта будет сформирован автоматически По хорошему, лучше эту галку не ставить. Пусть id формируется автоматически. Тот факт, что id в разных системах будут отличаться, как правило, не критично, кроме отдельных специфических ситуаций Подозреваю, что кто-то решил посмотреть, что будет, если эту галку установить. Ну и получили конфликт ранее созданных объектов и перенесенных значений id. Тут только пересоздавать индексы заново. Т.е. именно что удалить и создать заново
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... Последний раз редактировалось Владимир Максимов; 17.12.2020 в 19:26. |
|
![]() |
#9 |
Мрачный тип
|
Хронология создания объектов в разработческой среде (и последовательность выделения ID создаваемым объектам) отличалась от хронологии создания этих объектов в рабочей среде - вполне естественное явление при любом варианте разработки, будь то разработка нескольких проектов одновременно несколькими разработчиками или разработка одного проекта одним разработчиком.
Упомянутую галку экспорта с кодами объектов можно использовать только в том случае, когда изначально все модификации между рабочей и тестовой средами переносились с ее использованием и в рабочей ничего самостоятельно не создавалось - этим достигнется возможность безболезненного переноса между средами объектов, завязанных на ID других объектов (View, Query и т.д.), и каких-либо настроечных метаданных с завязками на на ID-объектов, ежели таковые используете... Во всех остальных случая, когда имеется нарушение вышеозвученного принципа и весьма вероятны разбегания значений ID одних и тех же объектов в разных средах - эту галку из диалога экспорта лучше скрыть от греха подальше и не использовать, ибо времени на перенос ID-зависимых объектов вручную потратится куда меньше, чем на ручное разгребания конфликтов ID
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 18.12.2020 в 06:59. |
|
|
За это сообщение автора поблагодарили: Мышелов Федор (1). |
![]() |
#10 |
Участник
|
Спасибо всем кто принял участие в решении проблемы, Ваши советы и предложения очень помогли в понимании ошибки и поиске пути ее решения.
Ошибка была устранена путем копирования одного рабочего приложения и замены скопированным другого, еще аз спасибо всем кто отозвался. |
|