Ошибки при синхронизации

[Мышелов Федор]

Добрый вечер.
Недавно перенес очередной проект на рабочее приложении, в проекте несколько таблиц несколько классом... Так вот после переноса запустил компиляцию проекта и синхронизацию таблиц проекта и при синхронизации получил вот такое сообщение. Сообщение пропало только после того как я снял со всех таблиц перенесенного проекта индексы, но буквально сегодня прилетела новая проблема с этим проектом и таблицами из него. Система выдала вот такую прелесть [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

[AlGol]

Похоже, что где-то в коде запроса указан hint для использования индекса по recid таблицы. После того как вы отключили индексы, код, который их использует будет выдавать ошибки.
Нужно или включить индексы и сделать ревизию кода на необходимость использования hintов при запросе к таблицам.

[Мышелов Федор]

проблема в том что hint - овых индексов там нет, а проблема проявилась после переноса проекта и говорила, что не может внести изменения в индекс (не на стороне Ax а на стороне Sql сервера alter index....) и исчезла после того как я снес все индексы на таблицах проекта. А теперь на сколько я понял система сама сделала индекс по RecId и не может что - то с ним сделать, что и приводит к ошибке.

[Pustik]

Посмотрите есть ли у Вас записи с одинаковым RecId в этой проблемной таблице? В AX2009, например (на скриншоте видно что у вас или 3.0 или 4.0 - поэтому не знаю сейчас как там), не создать даже не уникальный индекс на поле RecId, если есть 2 записи с одинаковым RecId. Решив проблему с такими записями, решалась и проблема создания индекса!

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

Индекс может отсутствовать по 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 Но при формировании запроса к SQL будет автоматически добавлять префикс. Из переменных значений тут только id-таблицы

При обновлении таблиц их id не менялся? Или может Axapta при каких-то условиях "теряет" корректное значение id-таблиц?

[Мышелов Федор]

Действительно, на одном приложении Id элемента 51210 на другом 51207, это порождает следующий вопрос, а точнее два. Как такое могло случится, а самое главное как это лечить

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

Цитата:

Сообщение от Мышелов Федор

Действительно, на одном приложении Id элемента 51210 на другом 51207, это порождает следующий вопрос, а точнее два. Как такое могло случится, а самое главное как это лечить

При экспорте/импорте XPO в старых версиях была галка вроде "Экспортировать со значениями кодов". Под термином "код" как раз и подразумевалось id. На картинке от версии dax4. Возможно, в dax3 она как-то по другому называлась

Соответственно, если галку устанавливать, то новый объект будет создан с переданным id (если это возможно). Если галку не ставить, то id нового объекта будет сформирован автоматически

По хорошему, лучше эту галку не ставить. Пусть id формируется автоматически. Тот факт, что id в разных системах будут отличаться, как правило, не критично, кроме отдельных специфических ситуаций

Подозреваю, что кто-то решил посмотреть, что будет, если эту галку установить. Ну и получили конфликт ранее созданных объектов и перенесенных значений id. Тут только пересоздавать индексы заново. Т.е. именно что удалить и создать заново

[TasmanianDevil]

Цитата:

Сообщение от Мышелов Федор

Как такое могло случится

Хронология создания объектов в разработческой среде (и последовательность выделения ID создаваемым объектам) отличалась от хронологии создания этих объектов в рабочей среде - вполне естественное явление при любом варианте разработки, будь то разработка нескольких проектов одновременно несколькими разработчиками или разработка одного проекта одним разработчиком.

Упомянутую галку экспорта с кодами объектов можно использовать только в том случае, когда изначально все модификации между рабочей и тестовой средами переносились с ее использованием и в рабочей ничего самостоятельно не создавалось - этим достигнется возможность безболезненного переноса между средами объектов, завязанных на ID других объектов (View, Query и т.д.), и каких-либо настроечных метаданных с завязками на на ID-объектов, ежели таковые используете...

Во всех остальных случая, когда имеется нарушение вышеозвученного принципа и весьма вероятны разбегания значений ID одних и тех же объектов в разных средах - эту галку из диалога экспорта лучше скрыть от греха подальше и не использовать, ибо времени на перенос ID-зависимых объектов вручную потратится куда меньше, чем на ручное разгребания конфликтов ID

[Мышелов Федор]

Спасибо всем кто принял участие в решении проблемы, Ваши советы и предложения очень помогли в понимании ошибки и поиске пути ее решения.

Ошибка была устранена путем копирования одного рабочего приложения и замены скопированным другого, еще аз спасибо всем кто отозвался.

[EVGL]

Это у вас Axapta 3.0 и Windows XP? Вот это да!!
В древних версиях системы была форма SQL Administration или типа того, и какая-то кнопка справа для лечения и перестройки индексов?
Вот, нашел в чуть менее раритетной системе:



Кажется, лет десять назад было еще принято удалять строки в SQLDICTIONARY и пересинхронизировать.