Доступность собственных таблиц после импорта проекта

[S.Kuskov]

Конфигурационное дерево строится по иерархии ConfigurationKey. У каждого ключа есть ссылка на родительский. Таким образом, зная целевой ключ, можно поднявшись по иерархии в AOT, понять в каком узле дерева он лежит

А по поводу таинства операции синхронизации... Она нужна для того чтобы привести БД в соответствие со словарём данных AOT.

[Narayana]

Цитата:

Сообщение от S.Kuskov

А по поводу таинства операции синхронизации... Она нужна для того чтобы привести БД в соответствие со словарём данных AOT.

А словарь данных, - это совокупность определения таблиц?
То есть, если в АОТе появилась новая таблица, то с помощью синхронизации эта таблица создается в БД?

А что такое обновление AOD?

И еще... а нет ли возможности импортировать не весь проект целиком, а предварительно выбрав только нужные объекты?
Вроде бы, галочка "Отобразить подробности" в форме импорта проекта относится только к выбору меток...?

[S.Kuskov]

Цитата:

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

А словарь данных, - это совокупность определения таблиц?
То есть, если в АОТе появилась новая таблица, то с помощью синхронизации эта таблица создается в БД?

Таблиц и Представлений(View) с учётом конфигурационных ключей.

Цитата:

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

А что такое обновление AOD?

Эта операция, если я ничего не путаю, актуальна в случае нескольких AOS, работающих с одним приложением.

Цитата:

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

И еще... а нет ли возможности импортировать не весь проект целиком, а предварительно выбрав только нужные объекты?
Вроде бы, галочка "Отобразить подробности" в форме импорта проекта относится только к выбору меток...?

Да нет, если не выбран режим "только метки" или что-то в этом роде, то в подробностях отображается весь состав проекта с возможностью выбора и даже предварительного сравнения.

[Narayana]

Цитата:

Сообщение от S.Kuskov

Да нет, если не выбран режим "только метки" или что-то в этом роде, то в подробностях отображается весь состав проекта с возможностью выбора и даже предварительного сравнения.

Попрактиковался.
Интересно получается.
Если наш проект имеет список объектов, в котором не только разработанные нами объекты, но еще и изначальные объекты системы, то, насколько я понял, изначальные объекты не ипортируются, но в импортированном проекте отображаются...
И синхронизация с базой должна проводиться не только во время импорта, но и в том случае, если мы решаем удалить импортированный проект, например, удалением слоя axusr.aod ? При этой синхронизации из базы должны удалиться лишние таблицы, да?

Но, у меня возникают при таком подходе странные явления.
Первый раз мой проект нормально импортировался.
Затем я его снес удалением слоя USR и импортировал другую версию проекта.
Возникли ошибки. Причем при компиляции класса слоя GLS, который я в своем проекте не изменял. Как-то очень странно. Снова убиваем слой USR и этот класс начинает нормально сохраняться и компилироваться...

Не знаете, чем это может быть обусловлено?

И еще такой вопросик, - Глобальная компиляция, это тоже самое, что, если открыть АОТ и его весь откомпилировать?

[S.Kuskov]

Цитата:

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

Попрактиковался.
Интересно получается.
Если наш проект имеет список объектов, в котором не только разработанные нами объекты, но еще и изначальные объекты системы, то, насколько я понял, изначальные объекты не ипортируются, но в импортированном проекте отображаются...

И отображаются и импортируются. Там ещё диалог с предупреждением должен выскакивать, мол импортируемый объект уже присутствует в системе.

Цитата:

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

И синхронизация с базой должна проводиться не только во время импорта, но и в том случае, если мы решаем удалить импортированный проект, например, удалением слоя axusr.aod ? При этой синхронизации из базы должны удалиться лишние таблицы, да?

Удаление слоя нужно делать при остановленной службе AOS, и вместе с файлом слоя *.aod желательно также удалить и файл *.aoi.

Цитата:

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

Но, у меня возникают при таком подходе странные явления.
Первый раз мой проект нормально импортировался.
Затем я его снес удалением слоя USR и импортировал другую версию проекта.
Возникли ошибки. Причем при компиляции класса слоя GLS, который я в своем проекте не изменял. Как-то очень странно. Снова убиваем слой USR и этот класс начинает нормально сохраняться и компилироваться...

Не знаете, чем это может быть обусловлено?

Сходу сложно сказать. А что за ошибки?
Чисто теоретически ошибка в классе слоя GLS, который вы не изменяли, может быть следствием ошибки в другом классе. Например, если метод A не содержит явных ошибок, но он из себя вызывает метод B, и это метод B по какой-то причине неоткомпилирован, то компиляция метода A также не будет успешна.

Цитата:

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

И еще такой вопросик, - Глобальная компиляция, это тоже самое, что, если открыть АОТ и его весь откомпилировать?

Не совсем. Операция глобальной компиляция выполняет несколько проходов компиляции.

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

[sukhanchik]

Цитата:

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

И еще такой вопросик, - Глобальная компиляция, это тоже самое, что, если открыть АОТ и его весь откомпилировать?

Цитата:

Сообщение от S.Kuskov

Не совсем. Операция глобальной компиляция выполняет несколько проходов компиляции.

Компиляция всего АОТа также делает несколько проходов (в АХ2009 - 2 полных и 3-й неполный). Так что можно считать, что это тоже самое

[Narayana]

Цитата:

Сообщение от S.Kuskov

Сходу сложно сказать. А что за ошибки?
Чисто теоретически ошибка в классе слоя GLS, который вы не изменяли, может быть следствием ошибки в другом классе. Например, если метод A не содержит явных ошибок, но он из себя вызывает метод B, и это метод B по какой-то причине неоткомпилирован, то компиляция метода A также не будет успешна.

Да, так и оказалось.
Вызов метода в классе с ошибкой происходил с параметром, неверно определенном в другом месте.