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

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

Индекс может отсутствовать по 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

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

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

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