if (record) vs if (record.RecId)

[kashperuk]

Ссылки по теме (в них много jobs по теме):
А RecId может быть отрицательным?
if (record) в случае join с использованием group by
Проверка на RecId

static void Job1(Args _args)
{
    InventTable invTbl = InventTable::find("OL-1000");
    ;
    if (invTbl)
    {
    }
    
    if (invTbl.RecId)
    {
    }
}

Вот еще job, из-за которого я собственно и начал дискуссию:

Добавьте этот метод на таблицу Address.

static server void doIt(Address _a)
{
    if (_a)
    {
        info("passed if(buffer) check in method");
    }
    
    if (_a.RecId)
    {
        info("passed if(buffer.recId) check");
    }
}

Перекройте метод create на источнике данных Address формы Address:

public void create(boolean _append = false)
{
    super(_append);

    if (address)
     info("passed if (address) in datasource");
    if(address.RecId)
     info("passed if (address.recId) in datasource");

     Address::doIt(address);
     
}

Какой из вариантов, по вашему мнению, должен использоваться?

[Lemming]

if (table.RecId != 0)

Не помню какую страшилку про if(record) прочел на форуме, но после нее приучил себя писать так, хотя возможно это и лишнее...

[glibs]

Мне показалось, что в прошлом уже пришли к решению. Проверка по RecId не сработает на сгруппированном источнике данных, и если в запросе указать список полей, в который не входит RecId. Посему она менее универсальна.

Опять же, как трактовать сформированный но невставленный буфер.

Хотя одно время я испытывал сложности с временными таблицами. Там мне приходилось делать проверку именно на RecId. На буфер что-то не срабатывало. Но я в последнее время с таким не сталкивался, а старые случаи по памяти описать не могу. Может что и путаю. Если наткнусь — отпишу сюда.

[oip]

Я почти всегда использую if (record). Проблем вроде не встречал. Почему именно так - не знаю. Особо никогда не анализировал.

[anykey]

не совсем понял, почему нельзя использовать проверку по RecID при указании списка полей для выборки.
Если я верно понял, не должна срабатывать проверка таког вида:

if((select firstonly AccountNum from custTable).RecId)
        info ("Found");

?
А вообще стараюсь использовать только проверку по RecId (опять таки не помню почему, что-то читал по этому поводу), исключая случаи проверки невставленных записей и сгруппированных рез-тов.

[ZVV]

Всегда использую if (record), держа в голове ситуацию с группировками, джоинами и списками полей, естественно.

[sukhanchik]

Ответил if (record) - хотя часто выборка курсора делается в одном методе, а проверка - в другом. В этом случае - строка return record вызывает ошибку - т.к. к boolean такая конструкция не приводится. Приходится писать return record.RecId != 0.
Проверку if (record.RecId !=0) опасно делать, когда имеешь дело с группировками.
Проверку if (record.RecId) опасно было делать до того как подправили багу по преобразованию int в boolean.
А дальше осталась сила привычки - if (record) работает железно - так почему бы им не пользоваться и не помнить про лишние грабли?

[MikeR]

С самого начала писал if (record), бо столкнулся с тем, что (record.RecId !=0) && f (record.RecId) не всегда отрабатывают

[anykey]

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

[AndyD]

2 anykey
Прошу прощение, но пример в этом посте

    select count(purchId) purchTable where
        purchTable.purchId == "Do not exist";
    if (purchTable)
    {
        info("The record exists!");
}

некорректен.
По этому запросу из базы данных будет возвращен курсор, со значением в агрегатной функции равным нулю. И аксапта абсолютно правильно говорит об этом - значение найдено. А то, что оно равно 0 - так про это и спрашивали, собственно.
Вот если бы агрегатная функция была max() или min(), а условие срабатывало, то это бы был явный косяк Аксапты.

Что касается меня, то использую, в основном, if (record)

[zemlyn]

а по-моему надо использовать по-прямому назначению

if(address.RecId) - если выбираем всю запись

if(address.(какое-то поле)) - если используем группировку (да-да, и поменьше копипастить, коллеги )

if(address) -- если пользуем как некоторую табличную переменную

х++ крайне расхолаживает из-за дырявости и многофункциональности использования таблич.переменных (говорю на примере ax3.0)

[kashperuk]

Хотелось бы значит, чтобы все, кто ответил if (record), еще попробовали второй пример из моего первого поста - в том, довольно простом случае получается, что if (record) не срабатывает.
Вопрос: должен ли? Почему?

[ZVV]

Цитата:

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

Хотелось бы значит, чтобы все, кто ответил if (record), еще попробовали второй пример из моего первого поста - в том, довольно простом случае получается, что if (record) не срабатывает.
Вопрос: должен ли? Почему?

Пробовал, но вообще-то у меня они оба не срабатывают, и if (record) , и if (recID) (на 3.0). А должно было быть по-другому?

Мне кажется что не должен и поведение разумное.

[kashperuk]

На АХ 2009 (вроде как и раньше - я проверю) срабатывает первый - if (record)

[ZVV]

Цитата:

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

На АХ 2009 (вроде как и раньше - я проверю) срабатывает первый - if (record)

Я ж так понял речь про пример с "Address"?

[ZVV]

Цитата:

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

На АХ 2009 (вроде как и раньше - я проверю) срабатывает первый - if (record)

Ха. Сорри, недотестировал.
Правильнее будет сказать так: может сработать, может нет.
Не срабатывает когда в гриде нет записи ещё (например, когда открываете альтерантивный адрес по клиенту) и вы создаёте первую новую. (или уже есть, но незаполненная )
Если же открываете, а там уже есть запись, то действительно if (record) срабатывает.
При этом визуально табличные переменные одинаково выглядят.

Забавно.
Видимо дело тут в этой самой привязке табличной переменной к курсору.
Иначе объяснить не могу.

Лично моё мнение - баг, срабатывать не должно.

[AndyD]

Такое впечатление, что при инициализации новой записи внутри метода super() не все внутренние переменные сбрасываются. Если перед вызовом super() сделать address = null;, то if (record) перестанет срабатывать.

Еще такой момент. Если открыть форму без записей, а потом создавать в ней новые не закрывая, то if (record) не срабатывает. Если же в форме при открытии есть записи, то, даже после удаления их, при добавлении новой if (record) начинает срабатывать

[ZVV]

Цитата:

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

Еще такой момент. Если открыть форму без записей, а потом создавать в ней новые не закрывая, то if (record) не срабатывает. Если же в форме при открытии есть записи, то, даже после удаления их, при добавлении новой if (record) начинает срабатывать

Да, есть такое, я же об этом уже писал в предыдущем сообщении.

[AndyD]

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