Это история одного ламерского бага, который я недавно, так-сказать, создал. Может будет полезно начинающим или условно начинающим, таким же как и я. В общем, стояла задача расширенного поиска кастомеров. Отдельными критериями поиска были адресные поля, но не стандартные, а из адреса доставки(delivery). Результат поиска отображался с помощью формочки с CustTable'овским источником данных, у которого был перегружен запрос на executeQuery. В общем, сам запрос этот был весьма бесхитростным, кроме некоторых нюансов, которые для этой темы, по большому счету, не важны. Важно то, что к CustTable"овскому источнику джоинился источник Address. И важно как: inner join. Ну и следовательно, следуя методу find таблицы Address выставлялись значения рэнджей этого источника. Фрагмент кода для наглядности:
X++:
addressDS = custTableDS.addDataSource(tablenum(Address));
addressDS.addLink(fieldnum(CustTable, RecId), fieldnum(Address, AddrRecId));
addressDS.addRange(fieldnum(Address,AddrTableId)).value(queryValue(tablenum(CustTable)));
addressDS.addRange(fieldnum(Address,Type)).value(queryValue(AddressType::Delivery));
Так вот, во всех компаниях поиск работал, как надо. Во всех, кроме одной. В этой самой «одной» получалась следующая картинка: каждый найденый кастомер отображался 2 раза. То есть грид содержал 2 идентичных записи(на форме отображались только записи из CustTable). Так вот, оказалось причина именно в связи 1:1. Оказалось, что индекс TypeIdx таблицы Address, содержащий поля AddrTableId, AddrRecId, AddressType (именно те поля, по которым работает find) не уникальный. Не спроста в find есть спецификатор firstonly. Так что у каждого кастомера может быть дофигища адресов доставки. Оказалось, что в этой компании именно такая ситуация(а точнее по 2 деливери адреса) и наблюдалась. Может в результате неправильного data migration, может просто фишка такая. И что интересно, зачем в системе допущена такая возможность и как дифферинциировать эти 2 адреса, если тот же файнд учитывает только вышеуказанные 3 критерия – для меня загадка. Но, тем не менее, будьте бдительны, граждане! После изменения типа связи с inner join на exist join все заработало «правильно». «Правильно», потому что анализироваться будут всегда первые адреса доставки.