Common.reread() - альтернатива для findRecId?

[S.Kuskov]

Хочу поинтересоваться у общественности - на сколько "правомочно" использовать следующий приём?

static void JobTestCommonReread(Args _args)
{
    InventTable InventTable;
    InventTable InventTable2;
    RecId RecId;
    ;

    select firstonly InventTable;
    RecId = InventTable.RecId;

    InventTable2.RecId = RecId;
    InventTable2.reread();
    
    info(InventTable2.ItemId);
}

В сочитании с common.selectForUpdate такой подход может быть очень полезен. Например, можно, не вводя новые переменные, "перевыбрать" курсор для обновления:

    // myTable не выбирался для обновления, но нам понадобилось изменить в нём данные
    myTable.selectForUpdate(true);
    ttsbegin;
    myTable.reread();
    ... 
    myTable.update();
    ttscommit;
    myTable.selectForUpdate(false);
}

[S.Kuskov]

Продолжил эксперименты с джобом JobTestCommonReread. Метод reread() в комбинации с методом clear() ведёт себя не столь очевидно.

static void JobTestCommonReread(Args _args)
{
    InventTable InventTable, InventTable2;
    RecId RecId;
    ;

    select firstonly InventTable;
    RecId = InventTable.RecId;

    InventTable2.RecId = RecId;
    InventTable2.reread();
    info(InventTable2.ItemId);
    
    InventTable2.clear(); // ???
    
    InventTable2.RecId = RecId;
    InventTable2.reread();
    info(InventTable2.ItemId); // ???
}

Что же такое делает метод clear и как гарантированно "перевыбрать" запись при помощи reread?

[lev]

не знаю на сколько правомочно, но то что очень удобно это точно!
когда не знаешь будешь изменять записи в таблице или нет, и обновление выполняется при определенных условиях.

пользуюсь этим регулярно, и пока никаких проблем не было

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

[lev]

Zitat:

Zitat von S.Kuskov

Продолжил эксперименты с джобом JobTestCommonReread. Метод reread() в комбинации с методом clear() ведёт себя не столь очевидно.
...
Что же такое делает метод clear и как гарантированно "перевыбрать" запись при помощи reread?

так clear() вычищает курсор который был выбран (если ошибаюсь, то меня поправят), соответственно после него нечего перевыбирать.
reread() - это не аналог find(), а метод для перезагрузки курсора из базы.

[lev]

кстати про findRecId.
я в одно время создал статический метод Find() в классе SysDictTable. в этом методе выполняется поиск по переданному RecId в таблице, Id которой так же передается в метод. Сделал это для того, что бы не заморачиваться написанием методов FindRecId на каждой таблице. Ведь поиск по RecId не так часто делается, да и пользоваться им нужно с умом, ведь не всегда есть индекс по RecId.

[S.Kuskov]

Zitat:

Zitat von lev

так clear() вычищает курсор который был выбран (если ошибаюсь, то меня поправят), соответственно после него нечего перевыбирать.

Но можно попытаться явно присвоить RecId. В моём первом примере курсор InventTable2 не был проинициалицирован, но reread() сработал, если же курсор стереть явно, при помощи clear, то reread перестаёт работать (второй пример). В чём принципиальная разница между непроинициализированным курсором и курсором после clear()?

[samolalex]

Поэкспериментировав, пришел к выводу, что нужно обнулить ссылку на область памяти, на которую ссылается табличная переменная. В итоге гарантированно "перевыбрать" запись при помощи reread можно так:

static void JobTestCommonReread(Args _args)
{
    InventTable     InventTable, InventTable2;
    RecId           RecId;
    ;
    select firstonly InventTable;
    RecId = InventTable.RecId;

    InventTable2.RecId = RecId;
    InventTable2.reread();
    info(InventTable2.ItemId);

    InventTable2.clear();
    inventTable2 = null;

    InventTable2.RecId = RecId;
    InventTable2.reread();
    info(InventTable2.ItemId);
}

[lev]

Zitat:

Zitat von S.Kuskov

Но можно попытаться явно присвоить RecId. В моём первом примере курсор InventTable2 не был проинициалицирован, но reread() сработал, если же курсор стереть явно, при помощи clear, то reread перестаёт работать (второй пример). В чём принципиальная разница между непроинициализированным курсором и курсором после clear()?

хм... странно.
про clear() я думаю все понятно, и он делает то что я написал выше.
скорее встает вопрос, а как же работает метод reread() ??? получается ему для выбора кроме RecId нужно ещё что то, что вычищается после использования метода clear().

[lev]

Zitat:

Zitat von samolalex

Поэкспериментировав, пришел к выводу, что нужно обнулить ссылку на область памяти, на которую ссылается табличная переменная. В итоге гарантированно "перевыбрать" запись при помощи reread можно так:
...

Тоже подумал про NULL, но меня опередили

[samolalex]

Zitat:

Zitat von lev

получается ему для выбора кроме RecId нужно ещё что то, что вычищается после использования метода clear().

тоже так думаю

[S.Kuskov]

Zitat:

Zitat von lev

получается ему для выбора кроме RecId нужно ещё что то, что вычищается после использования метода clear().

Т.е. курсор равный NULL, содержит больше информации, чем курсор.clear()?

Скорее наоборот clear() оставляет в курсоре какой-то мусор, который мешает работе reread

[lev]

Zitat:

Zitat von S.Kuskov

Т.е. курсор равный NULL, содержит больше информации, чем курсор.clear()?

Скорее наоборот clear() оставляет в курсоре какой-то мусор, который мешает работе reread

ага именно! не правильно выразился

[sukhanchik]

Zitat:

Zitat von S.Kuskov

Скорее наоборот clear() оставляет в курсоре какой-то мусор, который мешает работе reread

Достаточно посмотреть в отладчик, чтобы понять, что clear() устанавливает все поля в их "нулевое" или "начальное" состояние. В частности, попутно устанавливаются и системные поля (например, код компании).

Попробуйте выполнить такой код. В нем reread честно отработает (вспоминаем, что в БД индекс состоит из двух полей - RecID и dataareaid, т.о. выбрать запись просто по RecId система не может - ей нужен еще dataareaid):

static void Job1(Args _args)
{
    InventTable inventTable;
    ;
    inventTable.clear();
    breakpoint;
    inventTable = null;
    inventTable.(fieldnum(InventTable, dataAreaId)) = 'dat';
    inventTable.RecId = 5637147343;
    inventTable.reread();
    breakpoint;
}

[lev]

Zitat:

Zitat von sukhanchik

Достаточно посмотреть в отладчик, чтобы понять, что clear() устанавливает все поля в их "нулевое" или "начальное" состояние. В частности, попутно устанавливаются и системные поля (например, код компании).

Попробуйте выполнить такой код. В нем reread честно отработает (вспоминаем, что в БД индекс состоит из двух полей - RecID и dataareaid, т.о. выбрать запись просто по RecId система не может - ей нужен еще dataareaid):

static void Job1(Args _args)
{
    InventTable inventTable;
    ;
    inventTable.clear();
    breakpoint;
    inventTable = null;
    inventTable.(fieldnum(InventTable, dataAreaId)) = 'dat';
    inventTable.RecId = 5637147343;
    inventTable.reread();
    breakpoint;
}

что то я не понял.
если посмотреть в отладчике, после выполнения метода clear() поле DataAreaId остается со значением компании (то значение, которое было в выбранном курсоре). Затем ещё присваивается значение полю RecId. Получается перед выполнением метода reread() у нас и так заполнены два нужных поля.

кстати, тут уже писалось, что если обнулить память для таблицы (выполнить присвоение переменной NULL), то reread() нормально работает. а в Вашем примере в начале вызывается clear(), а потом обнуляется переменная, поэтому все нормально отрабатывает

[S.Kuskov]

dataAreaId - это первое, что я проверил . sukhanchik, на какой версии вы эксперементировали? На AX2009 clear не очищает поле dataAreaId, он принудительно заполняет его активной компанией.

И да, как правильно заметил lev, что будет если из вашего примера убрать строку "inventTable = null"?

P.S.: Демонстрация того, что при clear значение поля DataAreaId не просто не очищается, но даже принудительно меняется на значение текущей компании

static void JobTestClearDataAreaId(Args _args)
{
    InventTable InventTable;
    ;
    
    InventTable.(fieldnum(InventTable, dataAreaId)) = "XXX";
    info(InventTable.dataAreaId);
    InventTable.clear();
    info(InventTable.dataAreaId);
}

[lev]

вот так:

static void Job1(Args _args)
{
    InventTable inventTable;
    ;
    inventTable.clear();
    breakpoint;
    //inventTable = null;
    inventTable.(fieldnum(InventTable, dataAreaId)) = 'dat';
    inventTable.RecId = 5637147343;
    inventTable.reread();
    breakpoint;
}

уже не работает

[lev]

Zitat:

Zitat von S.Kuskov

На AX2009 clear не очищает поле dataAreaId, он принудительно заполняет его активной компанией.

на Ах 3.0 поле dataAreaId тоже не вычищается.

[sukhanchik]

Zitat:

Zitat von S.Kuskov

dataAreaId - это первое, что я проверил . sukhanchik, на какой версии вы эксперементировали?

Я проверил на 4.0 SP2 (была оперативно под рукой).

Zitat:

Zitat von lev

вот так уже не работает

А... сорри, не так понял. Я то думал - что не хватает курсору после null-а. И решил что dataareaid. А речь шла про то, что clear() не позволяет делать reread().

Хотя... у меня вариант от lev отработал также (т.е. запись все равно выбралась). Проверял на другом RecId (исключил вариант кеша)

[sukhanchik]

Кстати и на DAX2009 RU5 также отработало как и на 4.0 SP2

[S.Kuskov]

Zitat:

Zitat von sukhanchik

Кстати и на DAX2009 RU5 также отработало как и на 4.0 SP2

Странно, правда я проверял на AX2009SP1 без ролапов. Может ли ещё кто-нибудь проверить?

К стати, "InventTable = NULL" так же как и clear() сбрасывет dataAreaId к значению текущей компании

static void JobTestClearDataAreaId_2(Args _args)
{
    InventTable InventTable;
    ;

    InventTable.(fieldnum(InventTable, dataAreaId)) = "XXX";
    InventTable = NULL;
    info(InventTable.dataAreaId);
}