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

[Gibrid]

Цитата:

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

а у вас не осталось бекапа базы модели с таким случаем ?
Есть ощущением что повреждается определение таблицы с одновременным затиранием кластерного и праймери индекса в шапке таблицы. Я такое встречал, но давно и редко бывало.

Нет, бэкапа такого нет.
А какие могут быть причины этого? И как проверить, что это действительно оно в следующий раз?

[Logger]

Цитата:

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

В общем жду повторения, собираю статистику...

Столкнулись с той же проблемой.
На временной TempDb табличке.

Проблема появилась после того как в конфигурации аоса включили index hint.
Вероятно у вас также включены index hint, поэтому одной из рекомендаций было бы отключить их. (это 1-й бит в узле hint в конфигурации аоса в реестре. Дефолтное значение там "2")

Еще я заметил что помогает, если явно указать в запросе
index имя индекса
(но не index hint имя индекса)
видимо это добавляет сортировку но подавляет кривой index hint. Но проблему решает.

Вы как-нибудь решили для себя вопрос ?

[Logger]

Поразбирались еще в проблеме.

Что было у нас.

Включили index hint в конфигурации аоса (ключ hint в реестре, поменяли значение с 2 на 3)
После этого ядро стало ставить в запросах index hint там где они указаны в коде явно.
А там, где явно в коде не указаны, ядро может подставить их по своему усмотрению в зависимости от условий фильтрации (если сочтет какой-либо индекс подходящим под условия). Или оставит бех хинтов.
В общем, поведение как в Ax3.0 KR1
Правда там (в Ax3) был еще флажок 512 который позволял отключать автоматический подбор хинтов.
Обсуждался тут :
Кто использует KR3 ?
Но в 2012-й он не работает.

При попытке явно указать такой флаг конфигурационная утилита пишет что:

Цитата:

An unsupported value for the hints option has been detected. The default value has been restored, which affects the following settings: - Allow INDEX hints in queries (off by default) - Include SUBSTR and LOWER in all SELECT statements to support Oracle mixed-case systems (off by default) - Include LTRIM in all SELECT statements to remove leading space from right-aligned columns (off by default). If you do not change the settings now, they will be saved with default values.

Ну и ладно.
В конкретном запросе автоподбор хинта ядром можно подавить, указав
index имя индекса
тогда добавится сортировка по указанному индексу но хинтов не будет.

Либо (как подсказал Glibs, за что ему respect) можно завести на табличке пустой выключенный индекс, например с именем NoHintIdx и указать его явно как хинта
index hint NoHintIdx
тогда никакого хинта не будет. Мы явно указали индексы хинт, поэтому ядро прекращает самодеятельность, но поскольку реального индекса такого в БД нет, то ничего не ставит.

Про кривое формирование текста запроса, я заметил что в одних случаях запрос к времянке идет нормально с таким именем

SELECT TOP 1 ... FROM tempdb."DBO".t105707_0152F6081B43458B87857CD84D429941 T1 WITH ( INDEX(i105707_I_105707PHONEIDX_0152F6081B43458B87857CD84D429941)) WHERE ...

а в другом случае с таким

SELECT TOP 1 ... FROM tempdb."DBO".t105707_0152F6081B43458B87857CD84D429941 T1 WITH ( INDEX(i105707_I_105707PHONEIDX_(null))) WHERE ...

т.е. ядро где-то теряет инфу об имени индекса или инфу о реальном имени SQL временной таблицы, подставляя вместо имени 0152F6081B43458B87857CD84D429941 значение (null) т.е. что-то недоинициализировано.

Стали разбираться, оказалось что это происходит после вызова метода xRecord.linkPhysicalTableInstance().
Похоже linkPhysicalTableInstance переназначает в ядре ссылки с одной таблички на другую, но не все данные копирует правильно. Что-то остается непроинициализированным. И проявляется это не всегда, а только при стечении обстоятельств.

А вот если для тех же целей воспользоваться парой методов xRecord.getPhysicalTableName() / xRecord.useExistingTempDBTable() то все хорошо. Хинты с правильными именами формируются.

Поэтому сделали на SysDictTable свой метод
и используем его вместо xRecord.linkPhysicalTableInstance()

/// <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;
        tableName = _record.getPhysicalTableName();

        _record.data(tmpRecord);
    }

    ret = _thisRecord.useExistingTempDBTable(tableName);

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

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

    return ret;
}

linkPhysicalTableInstance - вообще какой-то стремный и глючный.
Работа с TempDB-таблицами
Работа с TempDB-таблицами

поэтому сделали еще проверку BP. Класс SysBPCheckMemberFunction добавили метод checkSourceLinkPhysicalTableInstance

/// /// <summary>
/// Делаем запрет на вызов common.linkPhysicalTableInstance
/// </summary>

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

protected boolean checkSourceLinkPhysicalTableInstance(xRefTmpReferences _thisRefererences)
{
    boolean     ret = true;
    ;

    while select _thisRefererences
        where   _thisRefererences.Kind      == xRefKind::TableInstanceMethod
            &&  _thisRefererences.Reference == XRefReference::Call
            &&  _thisRefererences.Name      == methodStr(xRecord, linkPhysicalTableInstance)
    {
        this.addSuppressableError(#BPErrorTableLinkPhysicalTableInstance_MRC, // так удобнее
            _thisRefererences.Line,
            _thisRefererences.Column,
            strFmt(@'Вызов метода "%1.%2" лучше заменить на вызов метода %3::%4 Подробности в исходном коде %3::%4.',
                _thisRefererences.ParentName, // 1
                _thisRefererences.Name, // 2
                classStr(SysDictTable), // 3
                staticMethodStr(SysDictTable, linkPhysicalTableInstance_MRC) // 4
                )
            );
        ret = false;
    }

    return ret;
}

[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;
}

[Gibrid]

С ноября у нас больше случаев не было, поэтому особо не занимались.
Хинты выключены - везде стоит параметр 2. Видимо проблема изредка и без включения хинтов может возникнуть...
Попробуем функцию заменить на вашу версию.