Ax 2012 строит запрос с ошибкой в синтаксисе

[Logger]

Все что описал выше мы пробовали на
kernel 6.3.6000.8144

Взял последний доступный
kernel 6.3.6000.11008

все то же самое.

Бага не исправлена.
Обходной путь с заменой xRecord.linkPhysicalTableInstance() на SysDictTable::linkPhysicalTableInstance_MRC() решает вопрос.

[sukhanchik]

Цитата:

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

Бага не исправлена.

Ну... громко сказано, что это бага... Бага, которая проявляется при активации режима, от которого отказались (причем включение режима тоже нетривиальная штука) - багой не считается ))

А если серьезно - я считаю, что каждый софт должен заниматься своим делом. Не задача SQL Server считать бизнес-логику. Не дело АХ - указывать БД какой индекс брать.

[Logger]

Цитата:

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

А если серьезно - я считаю, что каждый софт должен заниматься своим делом. Не задача SQL Server считать бизнес-логику. Не дело АХ - указывать БД какой индекс брать.

Это просто вопрос выбора инструментария. С какой стороны проще оптимизатору запросов мозги вправлять. И что дешевле.
Разработчики аксапты считают, что все же можно использовать хинты. Вернули их в 365й. Хотя и изменили способ включения.

[sukhanchik]

Цитата:

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

Это просто вопрос выбора инструментария. С какой стороны проще оптимизатору запросов мозги вправлять. И что дешевле.
Разработчики аксапты считают, что все же можно использовать хинты. Вернули их в 365й. Хотя и изменили способ включения.

Соглашусь, хотя такой подход сродни подходу "А давайте мы баг-трекер задач на АХ по-быстрому наваяем - наработки же есть - модуль проекты можно задействовать".

Т.е. с т.з. разработчиков аксапты - они всегда будут за то, чтобы любую задачу решить средствами АХ, т.к. они понимают как ее решить и как управлять и поддерживать это решение.
В то же время такой подход расходится с генеральной линией Microsoft (который собственно изначально систему и делает), который наоборот пытается дробить систему на сервисы. Например, в той же 365-й:
- попытка вынести оповещения (бизнес-события) и Workflow Power Automate
- попытка вынести логику расчета сводного планирования (да, там много нюансов, но сам факт) во внешний сервис
- попытка вынести мониторинг импорта данных во внешний сервис
- про БД я уже и не говорю
- баг-трекер Azure DevOps - это система вне 365-й
- еще в более ранних версиях из АХ был вырезан OLAP-механизм

Экономическая составляющая конечно очень существенно влияет на выбор решения, однако на мой взгляд "правильный" баланс между ролями систем позволяет с минимальными проблемами их апгрейдить относительно независимо друг от друга с максимальным разделением ответственности между специалистами (условно, за выбор индекса должна отвечать как БД, так и ДБА, а не АХ и программист АХ. Строить BI-отчеты должны BI-щики с их инструментарием, а не программисты АХ с их инструментарием и т.д.)

При таком подходе - условная замена АХ на другую систему, работающую также с SQL Server позволит ДБАшнику также отвечать за взятие нужных индексов, а BI-щикам также строить свои отчеты.

[Logger]

Метод linkPhysicalTableInstance_MRC содержал ошибку, которая приводила к тому, что не всегда работало как надо.

Исправленная версия

/// <summary>
/// _thisRecord начинает ссылаться на данные _record
/// Метод сделан как замена стандартному xRecord.linkPhysicalTableInstance() чтобы обойти его ошибки.
/// подробнее см.
/// [url=https://axforum.info/forums/showthread.php?p=443440#post443440]Ax 2012 строит запрос с ошибкой в синтаксисе[/url]
/// [url=https://axforum.info/forums/showthread.php?p=437193#post437193]Работа с TempDB-таблицами[/url]
/// </summary>
/// <param name="_thisRecord">
/// Таблица, у которой переназначаются данные.
/// </param>
/// <param name="_record">
/// Таблица, на чьи данные теперь будут ссылаться
/// </param>
/// <returns>
/// Успешно или нет
/// </returns>
/// <remarks>
///
/// </remarks>

// CustCrmClientActivityDocTmp_MRC_Fix "Исправляем ошибку WITH ( INDEX(i105707_I_105707PHONEIDX_(null)))", PKoz3 22.01.2025

public static boolean linkPhysicalTableInstance_MRC(Common _thisRecord, Common _record)
{
    Common      tmpRecord;
    str         tableName;

    boolean     ret;
    ;

    tableName = _record.getPhysicalTableName();

    if (!tableName) // значит табличку не сохраняли еще
    {
        tmpRecord = _record.data();

        // см. RetailUtilities::getPhysicalTableName(_record);
        // Force instantiation of Temp DB table.

        // select generateonly firstOnly RecId from _record; // так не работает. Sql имя резервируется,
        // но потом useExistingTempDBTable() не подхватывает это имя

        // а так работает. Видимо потому, что физически табличка в БД создается.
        // _record.doInsert();
        // _record.doDelete();

        select firstOnly RecId from _record; // так тоже работает, но меньше телодвижений !

        tableName = _record.getPhysicalTableName();

        _record.data(tmpRecord);
    }

    ret = _thisRecord.useExistingTempDBTable(tableName);

    // ret = _thisRecord.linkPhysicalTableInstance(_record); // такой вариант вместо вызова useExistingTempDBTable() не работает
    // проверяли предположение что проблема была в том, что вызвали linkPhysicalTableInstance для непроинициализированного параметра
    // в котором еще нет физического имени таблицы (не в этом ли корень проблем ? Поэтому сперва принудительно инициализируем буфер,
    // чтобы вызов linkPhysicalTableInstance гарантированно шел на проинициализированном TempDb буфере)

    // Оказалось что нет - ошибка с хинтом воспроизводится после любого вызова linkPhysicalTableInstance
    // т.е. сам по себе linkPhysicalTableInstance - какой то кривой и что-то портит в xRecord, поэтому лучше
    // избегать вызовов linkPhysicalTableInstance

    return ret;
}