Не срабатывает skipDatabaseLog(true)

[jaran]

установлена MBS Axapta 3.0 CIS SP3 Build #9.2, MS SQL 2000

Перед удалением данных в таблице вызываются методы
skipDatabaseLog(true)
skipDeleteActions(true)
skipDeleteMethod(true)
но при этом данные в таблицу SysDatabaseLog почему-то попадают!!!

[S.Kuskov]

В AX2009 была обнаружена подобная ситуация. Массовое удаление записей через CCADOConnection

Цитата:

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

Если в ax2009 настроить Database Log И отключить его в коде, то запись в Database Log все равно пишется, но один раз на весь Delete_from и с пустым контейнером.

А в вашем случае что именно пишется в лог?

[jaran]

Пишется информация по всем удаленным записям.
Может быть проблема от того, что стоит клиентская часть более новая, чем приложение? (Клиент - SP6, приложение SP3)

[Logger]

По-моему всегда так и было.
skipDataBaseLog() влиял только на удаление и обновление выполняемое конструкциями

delete_from
update_recordset

Если же просто вызывать

delete()
update()

то не работало.

[mazzy]

Цитата:

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

Может быть проблема от того, что стоит клиентская часть более новая, чем приложение? (Клиент - SP6, приложение SP3)

Нет, версия приложения тут не причем.

Цитата:

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

По-моему всегда так и было.
skipDataBaseLog() влиял только на удаление и обновление выполняемое конструкциями

delete_from
update_recordset

Если же просто вызывать

delete()
update()

то не работало.

Разве? Конечно надо проверить, но skip действовал всегда, насколько я помню.

[George Nordic]

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

С Уважением,
Георгий

[Logger]

У меня не получалось добиться пропуска логирования для
delete()
update()

Сам удивлялся.

[Hyper]

Axapta 3.0 SP4, MS SQL Server 2000

SysDataBaseLog.insert() срабатывает при выполнении следующего кода:

static void Job6(Args _ars)
{
    VendTable vendTable;
    ;

    ttsbegin;

    vendTable.skipDatabaseLog(true);

    select forupdate firstonly vendTable
        where vendTable.AccountNum == "000002_313";

    vendTable.Name = 'Test9';

    vendTable.doUpdate();

    ttscommit;
}

Есть в тройке какая-то возможность заставить изменения не писаться в SysDataBaseLog?

[Logger]

использовать update_recordset
а также еще вызвать skipDataMethods(true)

[Hyper]

Цитата:

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

использовать update_recordset
а также еще вызвать skipDataMethods(true)

skipDataMethods не помогает (я все скипы пробовал ), а делать update_recordset индивидуально для каждой из сотен тысяч записей - идея интересная.

Я правильно понимаю, что skipDatabaseLog должен работать только для update_recordset, это функционал согласно дизайна Аксапты?

[Hyper]

Убедился, что в AX 2009 такой проблемы нет. skipDataBaseLog(true) вполне успешно отключает логирование.

В тройке это как-то лечится, никто не знает?

[Logger]

Цитата:

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

skipDataMethods не помогает (я все скипы пробовал ), а делать update_recordset индивидуально для каждой из сотен тысяч записей - идея интересная.

Я правильно понимаю, что skipDatabaseLog должен работать только для update_recordset, это функционал согласно дизайна Аксапты?

Насчет дизайна не знаю. Но работает. Т.е. в вашем случае надо использовать и update_recordset и skipDatabaseLog и skipDataMethods

Можно делать update_recordset индивидуально для каждой записи - ничего в этом такого нет. обычный update() отправляет схожий запрос. Ну или если у вас есть какой нить критерий по которому можно больше записей отобрать для обновления то его же можно запихнуть в условие update_recordset

[S.Kuskov]

а если vendTable.skipDatabaseLog(true) вызвать после select, а не до? Вдруг select сбрасывет значения флагов skip*

[Hyper]

Цитата:

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

а если vendTable.skipDatabaseLog(true) вызвать после select, а не до?

Пробовал - не получалось.

[Raven Melancholic]

Насколько я помню, у нас в Ax3.0 была та же проблема. В принципе, она не особо мешала кроме случаев массовой загрузки. При массовой загрузки мы:

• удалили запись в таблице настройки логирования.
• загрузили данные.
• восстановили настройку.

Причем, работал такой подход только в двухуровневой конфигурации. В трехуровневой без перезапуска AOS это не работало.