|
![]() |
#1 |
Участник
|
Условие where _common.recid == _common.recid равносильно условию where true или что тоже самое отсутствию условия. Если у вас в таблице (APMParameters) одна запись то она и выберется и вы не почувствуете разницы. На таблицах с несколькими записями такой запрос вернёт вам первую попавшуюся запись, а не обязательно ту с которой вы работали.
|
|
![]() |
#2 |
Участник
|
Цитата:
Сообщение от S.Kuskov
![]() Условие where _common.recid == _common.recid равносильно условию where true или что тоже самое отсутствию условия. Если у вас в таблице (APMParameters) одна запись то она и выберется и вы не почувствуете разницы. На таблицах с несколькими записями такой запрос вернёт вам первую попавшуюся запись, а не обязательно ту с которой вы работали.
X++: select table where true; А этот меняет. X++: select table where table.recId == table.recId; X++: Address address; RecId recId = 5637314047; ; select address where address.recId == recId; select address where address.recId == address.recId; // тут меняется recId //select address where true; // тут не меняется recId if (recId != address.RecId) info('меняется'); |
|
![]() |
#3 |
Участник
|
Ничего странного. Вообще оба запроса могут вернуть абсолютно любую запись случайным образом. Сегодня могут вернуть то, что было в первом запросе, завтра что-нибудь другое.
Оба запроса почти равнозначны. Просто в = true, скорее всего, вообще проигнорируется условие движком MS SQL (или Аксапты), второй что-нибудь попробует сравнить (а может и нет), но все равно для каждой записи таблицы условие выполняется. В базе в таблице хранится "неупорядоченный кортеж", если прямо не сортировать в самом запросе, то порядок выборки неопределен. Конечно, могут влиять кластерные индексы, кэшированные данные, фаза луны, расположение звезд. Но закладываться на то, что это постоянное влияние, не следует. В итоге, обсуждение чисто теоретическое и пользы, немного, какие бы предположения не делались. |
|
|
|