07.04.2009, 15:38 | #1 |
Участник
|
update_recordset. Бага или фича?
Есть код:
X++: ttsbegin; Table1 table1; ; select forupdate table1 where table1.filed2 == value; table1.Field1 = true; table1.update(); ttscommit; Следующий код: X++: Table1 table1; ; update_recordset table1 setting field1 = true where table1.field2 = value; По-моему это неправильно, поля modified должны меняться только тогда, когда изменилось значение какого-нибудь поля. Пытался отучить update_recordset от такой привычки Этот код не меняет поля ModifiedDate/Time : X++: ttsbegin; Table1 table1; ; table1.overwriteSystemfields(true); select forupdate table1 where table1.filed2 == value; table1.Field1 = true; table1.update(); ttscommit; А этот сбрасывает в 0 оба поля X++: Table1 table1; ; table1.overwriteSystemfields(true); update_recordset table1setting field1 = true where table1.field2 = value; Ax 3.0 SP3 Последний раз редактировалось Lucky13; 07.04.2009 в 15:42. |
|
|
За это сообщение автора поблагодарили: aidsua (1). |
07.04.2009, 16:04 | #2 |
MCTS
|
Цитата:
Пытался отучить update_recordset от такой привычки
X++: update_recordset table1 setting field1 = true where table1.field2 == value && table1.Field1 != true; |
|
07.04.2009, 16:28 | #3 |
Участник
|
Цитата:
Я имею в виду если поле было равно true и update хочет сделать true. Следовательно ничего не изменилось и modifieddate/time меняться не должны по идее, а они меняются. |
|
07.04.2009, 18:15 | #4 |
MCITP
|
Цитата:
Сообщение от Lucky13
Это понятно. Проблему это решит, но не поможет понять почему update_recordset работает не так, как обычный update.
Я имею в виду если поле было равно true и update хочет сделать true. Следовательно ничего не изменилось и modifieddate/time меняться не должны по идее, а они меняются. Если делается обычный update() то Акса проверяет, что хоть какое-то поле поменялось и если нет, то реального Апдэйта в БД не уходит. В случае же update_recordset если выполняются все необходимые условия (типа отсутствия перекрытого метода update(), отсутствия Лога БД или же если есть соответсвующие skipXXX()... это я думаю понятно....) на сервер БД сразу отправляется update вида: X++: UPDATE ...
SET FIELD=:in1,MODIFIEDDATE=:in2,MODIFIEDTIME=:in3
WHERE ... Всё логично... С точки зрения БД - это номальное как раз поведение, т.к. обновление реальное было. Перекройте метод Update() на таблице и получится первый вариант поведения (Аксаптовский)... Со всеми вытекающими по скорости.
__________________
Zhirenkov Vitaly |
|
07.04.2009, 18:20 | #5 |
Участник
|
Тогда и update_recordset реально не работает
|
|
07.04.2009, 18:31 | #6 |
MCITP
|
Естественно не работает, об этом написано мною выше...
PS Я не собирался здесь писать развёрнутый доклад на тему как и когда работает update_recordset... А толику юморf могли бы и включить...
__________________
Zhirenkov Vitaly |
|
08.04.2009, 10:31 | #7 |
Участник
|
Цитата:
Сообщение от ZVV
По-моему причины данного поведения достаточно очевидны.
Если делается обычный update() то Акса проверяет, что хоть какое-то поле поменялось и если нет, то реального Апдэйта в БД не уходит. В случае же update_recordset если выполняются все необходимые условия (типа отсутствия перекрытого метода update(), отсутствия Лога БД или же если есть соответсвующие skipXXX()... это я думаю понятно....) на сервер БД сразу отправляется update вида: X++: UPDATE ...
SET FIELD=:in1,MODIFIEDDATE=:in2,MODIFIEDTIME=:in3
WHERE ... Всё логично... С точки зрения БД - это номальное как раз поведение, т.к. обновление реальное было. Перекройте метод Update() на таблице и получится первый вариант поведения (Аксаптовский)... Со всеми вытекающими по скорости. |
|
08.04.2009, 17:33 | #8 |
MCITP
|
Цитата:
X++: UPDATE ...
SET FIELD=:in1,MODIFIEDDATE=01/01/1900,MODIFIEDTIME=0
WHERE ...
__________________
Zhirenkov Vitaly |
|
Теги |
modifieddate, modifiedtime, recordset, update_recordset, баг |
|
|