update in salesTable

[ashu]

Добрый день коллеги.
я не программист потому: пишу в курилке, могу не верно формулировать- больно не бить. есть простой джобик:

static void Job64(Args _args)
{
    SalesTable      salesTable;

    ;
    salesTable.selectForUpdate(true);

    select firstOnly salesTable;

    salestable.driver_W   = 'ssss2';

    salesTable.update();

    info(salesTable.SalesId);

внимание вопрос: должен ли отработать?
если да то почему? если нет то почему? а по факту как у вас получилось? на какой версии системы?

[mazzy]

перенес в программирование.

в ax3.0 и более ранних - сработает.
в ax4.0 и более поздних - не сработает, поскольку потребует обязательной транзакции.

если вопрос не про ttsbegin, а про "можно ли писать selectForUpdate(ture) вместо select forupdate"
то можно писать selectForUpdate(ture)

[pitersky]

Цитата:

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

в ax3.0 и более ранних - сработает.
в ax4.0 и более поздних - не сработает, поскольку потребует обязательной транзакции.

А разве не наоборот? В 3.0 точно не отработает без открытой транзакции

[ashu]

Цитата:

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

перенес в программирование.

в ax3.0 и более ранних - сработает.
в ax4.0 и более поздних - не сработает, поскольку потребует обязательной транзакции.

если вопрос не про ttsbegin, а про "можно ли писать selectForUpdate(ture) вместо select forupdate"
то можно писать selectForUpdate(ture)

dax 2009 ru4,5,6 срабатывает...
Сергей, есть возможномость проверить на практике?

[mazzy]

хм... да, был не прав.

ax3.0 - требует транзакции
ax2009 - срабатывает

[ashu]

"радует" что не только у нас такая ситуация.
потому и вопрос: Почему срабатывает? в чем сакральное различие мжеду версиями системы, ядра, БД? хочу понять баг или фича, по моему апдейт без тразакции - это не бестпрактикс...

PS добавлю, например на таблице custtable аналогичный джоб не отрабатывает, может быть свойста таблицы?, типа кеширования?, настройки СУБД?- вообщем загадка, давайте коллективным разумом разберемся- жуть как интересно стало...

[pitersky]

в своё время мне рассказывали, что, начиная с 4.0, транзакция на таблице открывается по умолчанию при выборе forupdate и закрывается после обновления. Мол, это сделано для того, чтобы не плодить вложенные открытия/закрытия транзакций.
Мне лично это кажется неудачным решением. Зачастую под транзакцией надо понимать обновление не только конкретной таблицы, но и связанных с ней. Не уверен, что можно корректно вычленить такие изменения, если транзакцию надо откатить, а её границы в явном виде не указаны.

[shlyopin]

Добрый вечер! Смею предположить, что дело в оптимистической модели данных включённой по умолчанию для этой таблицы (OCC Enabled = Yes) для версии AX 5.0. Если ее отключить, то результат без обрамленной транзакции будет: Невозможно отредактировать запись в Заказы на продажу (SalesTable). Невозможно выполнить операторы NEXT, update() или delete() с буфером, данные которого выбраны или вставлены в рамках другой транзакции. (Проверял на 5.0 1500 3761)

[AndyD]

Угум.
А еще наличие вызова ttsbegin/ttscommit ВНУТРИ метода update() "помогает" при включенной оптимистической конкуренции. Без это тоже будет исключение (сравните с вызовом doUpdate())

[S.Kuskov]

Цитата:

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

Угум.
А еще наличие вызова ttsbegin/ttscommit ВНУТРИ метода update() "помогает" при включенной оптимистической конкуренции. Без это тоже будет исключение (сравните с вызовом doUpdate())

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

А какова вообще может быть причина идти на риск редактирования записи не открывая заранее транзакцию? Когда такое может пригодиться?

[AndyD]

При оптимистической конкуренциии в DAX2009 что с транзакцией, что без нее выборка с forupdate (или с selectForUpdate(true)) не накладывает блокировки на выбираемые данные (при записи выполняется операция update ... where ... recVersion=[считанное ранее значение] и, если данные успели поменяться со времени последнего чтения и обновление не проходит, будет выброшено исключение "Запись удалена или изменена другим пользователем).

Так что, с точки зрения DAX2009, наличие транзакции в этом режиме при операции чтения никак не скажется на логике выполнения вышеприведенного кода (если только update выполняется внутри транзакции, конечно)