Поиск |
Результаты опроса: Какой из методов следует использовать? | |||
if (record) - Хорошо бы ответить в теме, почему |
![]() ![]() ![]() ![]() |
19 | 73.08% |
if (record.RecId) - Хорошо бы ответить в теме, почему |
![]() ![]() ![]() ![]() |
5 | 19.23% |
Свой вариант - Отписался в теме |
![]() ![]() ![]() ![]() |
2 | 7.69% |
Голосовавшие: 26. Вы ещё не голосовали в этом опросе |
|
Опции темы |
![]() |
#1 |
Участник
|
![]()
Ссылки по теме (в них много jobs по теме):
А RecId может быть отрицательным? if (record) в случае join с использованием group by Проверка на RecId X++: static void Job1(Args _args) { InventTable invTbl = InventTable::find("OL-1000"); ; if (invTbl) { } if (invTbl.RecId) { } } Добавьте этот метод на таблицу Address. X++: static server void doIt(Address _a) { if (_a) { info("passed if(buffer) check in method"); } if (_a.RecId) { info("passed if(buffer.recId) check"); } } X++: 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); } |
|
![]() |
#2 |
Участник
|
X++: if (table.RecId != 0) ![]() |
|
![]() |
#3 |
Member
|
Мне показалось, что в прошлом уже пришли к решению. Проверка по RecId не сработает на сгруппированном источнике данных, и если в запросе указать список полей, в который не входит RecId. Посему она менее универсальна.
Опять же, как трактовать сформированный но невставленный буфер. Хотя одно время я испытывал сложности с временными таблицами. Там мне приходилось делать проверку именно на RecId. На буфер что-то не срабатывало. Но я в последнее время с таким не сталкивался, а старые случаи по памяти описать не могу. Может что и путаю. Если наткнусь — отпишу сюда.
__________________
С уважением, glibs® |
|
![]() |
#4 |
Axapta
|
Я почти всегда использую if (record). Проблем вроде не встречал. Почему именно так - не знаю. Особо никогда не анализировал.
__________________
С уважением, Олег. Последний раз редактировалось oip; 27.11.2008 в 12:09. Причина: немного не так сначала написал |
|
![]() |
#5 |
Участник
|
не совсем понял, почему нельзя использовать проверку по RecID при указании списка полей для выборки.
Если я верно понял, не должна срабатывать проверка таког вида: X++: if((select firstonly AccountNum from custTable).RecId) info ("Found"); А вообще стараюсь использовать только проверку по RecId (опять таки не помню почему, что-то читал по этому поводу), исключая случаи проверки невставленных записей и сгруппированных рез-тов. Последний раз редактировалось anykey; 27.11.2008 в 12:07. |
|
![]() |
#6 |
MCITP
|
![]()
Всегда использую if (record), держа в голове ситуацию с группировками, джоинами и списками полей, естественно.
![]()
__________________
Zhirenkov Vitaly |
|
![]() |
#7 |
Administrator
|
Ответил if (record) - хотя часто выборка курсора делается в одном методе, а проверка - в другом. В этом случае - строка return record вызывает ошибку - т.к. к boolean такая конструкция не приводится. Приходится писать return record.RecId != 0.
Проверку if (record.RecId !=0) опасно делать, когда имеешь дело с группировками. Проверку if (record.RecId) опасно было делать до того как подправили багу по преобразованию int в boolean. А дальше осталась сила привычки - if (record) работает железно - так почему бы им не пользоваться и не помнить про лишние грабли?
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#8 |
MCT
|
С самого начала писал if (record), бо столкнулся с тем, что (record.RecId !=0) && f (record.RecId) не всегда отрабатывают
__________________
Axapta book for developer |
|
![]() |
#9 |
Участник
|
Если не ошибаюсь, то после этого поста стал стараться использовать проверку по RecId.
Хотя, ничего нового, к написанному выше это не добавляет ![]() |
|
![]() |
#10 |
Участник
|
2 anykey
Прошу прощение, но пример в этом посте X++: select count(purchId) purchTable where purchTable.purchId == "Do not exist"; if (purchTable) { info("The record exists!"); } По этому запросу из базы данных будет возвращен курсор, со значением в агрегатной функции равным нулю. И аксапта абсолютно правильно говорит об этом - значение найдено. А то, что оно равно 0 - так про это и спрашивали, собственно. Вот если бы агрегатная функция была max() или min(), а условие срабатывало, то это бы был явный косяк Аксапты. Что касается меня, то использую, в основном, if (record)
__________________
Axapta v.3.0 sp5 kr2 Последний раз редактировалось AndyD; 27.11.2008 в 14:50. |
|
![]() |
#11 |
Участник
|
а по-моему надо использовать по-прямому назначению
if(address.RecId) - если выбираем всю запись if(address.(какое-то поле)) - если используем группировку (да-да, и поменьше копипастить, коллеги ![]() if(address) -- если пользуем как некоторую табличную переменную х++ крайне расхолаживает из-за дырявости и многофункциональности использования таблич.переменных (говорю на примере ax3.0) |
|
![]() |
#12 |
Участник
|
Хотелось бы значит, чтобы все, кто ответил if (record), еще попробовали второй пример из моего первого поста - в том, довольно простом случае получается, что if (record) не срабатывает.
Вопрос: должен ли? Почему? |
|
![]() |
#13 |
MCITP
|
![]() Цитата:
Мне кажется что не должен и поведение разумное.
__________________
Zhirenkov Vitaly |
|
![]() |
#14 |
Участник
|
На АХ 2009 (вроде как и раньше - я проверю) срабатывает первый - if (record)
|
|
![]() |
#15 |
MCITP
|
![]()
Я ж так понял речь про пример с "Address"?
__________________
Zhirenkov Vitaly |
|
![]() |
#16 |
MCITP
|
![]() Цитата:
Правильнее будет сказать так: может сработать, может нет. ![]() Не срабатывает когда в гриде нет записи ещё (например, когда открываете альтерантивный адрес по клиенту) и вы создаёте первую новую. (или уже есть, но незаполненная ![]() Если же открываете, а там уже есть запись, то действительно if (record) срабатывает. При этом визуально табличные переменные одинаково выглядят. Забавно. Видимо дело тут в этой самой привязке табличной переменной к курсору. Иначе объяснить не могу. Лично моё мнение - баг, срабатывать не должно. ![]()
__________________
Zhirenkov Vitaly |
|
![]() |
#17 |
Участник
|
Такое впечатление, что при инициализации новой записи внутри метода super() не все внутренние переменные сбрасываются. Если перед вызовом super() сделать address = null;, то if (record) перестанет срабатывать.
Еще такой момент. Если открыть форму без записей, а потом создавать в ней новые не закрывая, то if (record) не срабатывает. Если же в форме при открытии есть записи, то, даже после удаления их, при добавлении новой if (record) начинает срабатывать
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#18 |
MCITP
|
![]() Цитата:
![]()
__________________
Zhirenkov Vitaly |
|
![]() |
#19 |
Участник
|
Я это видел.
Я хотел акцентировать внимание, что даже после удаления всех записей эффект не пропадает. Т.е., либо флаги прописываются где-то внутри формы, либо запись ассоциируется с формой и после удаления всех данных привязка остается.
__________________
Axapta v.3.0 sp5 kr2 |
|
Теги |
best practice, faq, recid |
|
|