Достать информацию об иерархии X++ табличек из базы модели

[Logger]

Привет всем.

Понадобилось в Transact-SQL понять по базе модели и имени конкретной X++ таблицы, есть у нее родительская или нет.

Можно как-то это понять ?

Пока нашел только, что имя родительской таблички хранится в [ModelElementData].[Properties]

static void _upg003_Table(Args _args)
{
    void aa(boolean    _short, str s)
    {
        int         imax;
        int         i;
        str         sout;
        ;

        imax = strLen(s);

        for (i = 1; i <= imax; i += 2)
        {
            sout += num2char(hex2Int(subStr(s, i, 2)));
        }
        info(sout);

        if (_short)
        {
            return;
        }

        for (i = 1; i <= imax; i += 2)
        {
            info(con2Str([i, subStr(s, i, 2), "   ", num2char(hex2Int(subStr(s, i, 2)))]));
        }
    }
    ;
    
    // пример  сделан для CompanyInfo
    // aa(1, "100008400053005900530031003200390031003000300000004F004D004C006500670061006C0045006E00740069007400690065007300000000004C006500670061006C00200065006E00740069007400790000000000000040005300590053003100320035003000340031000000F6DD0B8C4F004D0049006E007400650072006E0061006C004F007200670061006E0069007A006100740069006F006E00000003004400610074006100410072006500610000000202800001032A0053007500720072006F0067006100740065004B006500790000004B006500790000000203420061007300690063005400610062006C0065007300000000000043006F006D00700061006E00790049006E0066006F0045007800740065006E00730069006F006E005F0043004E0000000143006F006D00700061006E00790049006E0066006F00000054006100780049006E0066006F0072006D006100740069006F006E004C006500670061006C0045006E0074006900740079005F0049004E0000000143006F006D00700061006E00790049006E0066006F0000004C00650064006700650072000000015000720069006D0061007200790046006F0072004C006500670061006C0045006E00740069007400790000004B006500790000004800000000000000");
    aa(0, "100008400053005900530031003200390031003000300000004F004D004C006500670061006C0045006E00740069007400690065007300000000004C006500670061006C00200065006E00740069007400790000000000000040005300590053003100320035003000340031000000F6DD0B8C4F004D0049006E007400650072006E0061006C004F007200670061006E0069007A006100740069006F006E00000003004400610074006100410072006500610000000202800001032A0053007500720072006F0067006100740065004B006500790000004B006500790000000203420061007300690063005400610062006C0065007300000000000043006F006D00700061006E00790049006E0066006F0045007800740065006E00730069006F006E005F0043004E0000000143006F006D00700061006E00790049006E0066006F00000054006100780049006E0066006F0072006D006100740069006F006E004C006500670061006C0045006E0074006900740079005F0049004E0000000143006F006D00700061006E00790049006E0066006F0000004C00650064006700650072000000015000720069006D0061007200790046006F0072004C006500670061006C0045006E00740069007400790000004B006500790000004800000000000000");
}

выводит

Цитата:

@SYS129100OMLegalEntitiesLegal entity@SYS125041ö݌OMInternalOrganizationDataArea€*SurrogateKeyKeyBasicTablesCompanyInfoExtension_CNCompanyInfoTaxInformationLegalEntity_INCompanyInfoLedgerPrimaryForLegalEntityKeyH

т.е. можно оттуда достать, но на Transact-SQL это неудобно разбирать.

Есть способ попроще ?

Ax2012 R3

[S.Kuskov]

А в R3 наследуемые таблицы на уровне SQL сервера разве не представлены одной плоской таблицей?

[Logger]

Цитата:

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

А в R3 наследуемые таблицы на уровне SQL сервера разве не представлены одной плоской таблицей?

Да, представлены.

Но вопрос был в другом. Есть скрипт на Transact-SQL который обрабатывает базу с моделью. Как он поймет, например, что для таблички CompanyInfo и идентификатором 41 корневой является табличка DirPartyTable c идентификатором
2303

(я пишу скрипт, который после изменения идентификаторов в модели пробрасывает их в бизнесбазу в табличку SqlDictionary)

Подробнее, см
Программное воссоздание записей SqlDictionary для определенной таблицы

[gl00mie]

Цитата:

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

Есть скрипт на Transact-SQL который обрабатывает базу с моделью. Как он поймет, например, что для таблички CompanyInfo и идентификатором 41 корневой является табличка DirPartyTable c идентификатором 2303

Как на счет того, чтобы по аналогии с enum-ами (какая-то там таблица для SSRS) просто создать служебную таблицу с инфой об иерархии таблиц, заполнить ее из Х++, а потом обращаться из TSQL к этой таблице?

[Logger]

Цитата:

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

Как на счет того, чтобы по аналогии с enum-ами (какая-то там таблица для SSRS) просто создать служебную таблицу с инфой об иерархии таблиц, заполнить ее из Х++, а потом обращаться из TSQL к этой таблице?

Оказывается такая таблица уже есть.
\System Documentation\Tables\SysInheritanceRelations
живет в базе с данными (там же где SqlDictionary)
Случайно наткнулся.

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

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

Идея основана на следующих допущениях

1. Таблица, на основании которой создали наследников, имеет поле InstanceRelationType
2. Поля этой таблицы, которые были созданы в таблицах-наследниках, могут принимать значение Null
3. Таблица-наследник физически не существует в базе данных

Тогда логика такая

1. Ищем все таблицы, у которых есть поле InstanceRelationType. Это таблицы, по которым были созданы таблицы-наследники

К сожалению, просто посмотреть список значений в поле InstanceRelationType - недостаточно, поскольку там записывается Id той таблицы, где запись была создана. В некоторых таблицах записи просто не создаются.

Например, в таблице OMInternalOrganization. Хотя она прямой родитель CompanyInfo, но нет ни одной записи DirPartyTable, где InstanceRelationType равно Id этой таблицы


2. Отбираем все поля, которые могут иметь значение Null

Можно просто "все" поля, но так уменьшим объемы выборки. Тут, конечно, могут "помешать" контейнерные поля, которые имеют значение Null и без наследования, но это выяснится позже


3. В базе данных модели в таблице [ModelElement] ищем записи по этим полям (по имени поля) и смотрим, какое у них значение в поле ParentId. Это будет ссылка на ту таблицу-наследник, в которой это поле было физически создано

Можно здесь сразу закончить анализ, если поле ссылаются на одну из таблиц, код которой есть в поле InstanceRelationType анализируемой таблицы-родителя


4. Из списка найденных таблиц оставляем только те, которые физически не существуют в основной базе данных. Скорее всего, в итоге останется только одна таблица, которая и является таблицей-наследником

Есть, конечно, риск совпадения имен полей в разных таблицах-наследниках, но не проверял, насколько это частое явление


Это идея. Как это реализовать в виде запросов - не проверял. Но, вроде бы, все реализуемо