select com1.addr, per1.tabnmb, per1.fio, com2.addr, per2.tabnmb, per2.fio
from synonym communications com1, synonym communications com2 ,
synonym persons per1, synonym persons per2
where ((
com1.person == per1.nrec
and com2.person == per2.nrec))
and 07D0000000000240h=com1.comtype
and 07D0000000000240h=com2.comtype
and com2.person <> com1.person
and com1.addr=com2.addr
and length(trim(com1.addr))>0
and longint(per1.disdate)=0 and longint(per2.disdate)=0
order by per1.tabnmb;
отрабатывает как часы, а в фейсе - ну ничего не находит...
сортировка вьюшки по некорневой таблице запроса - дело в галактике загадочное и непредвещающее ничего хорошего. много раз видел глюки с этим связанные
дальше
не проще ли вместо
length(trim(com1.addr))>0
просто
com1.addr <> ''
дальше, у communications есть индекс
PERSON+COMTYPE
над вашим запросом можно поработать
Я бы рекомендовал вообще забыть, что в Галактическом "SQL" есть order by, пока не набъете руку, иначе будете частенько натыкаться на глюки. Пользуйтесь для сортировки только индексами
В варианте запроса в интерфейсе таблица per1 (синоним persons) является, как я понимаю, корневой. Условие length(trim(com1.addr)) >0 согласна заменить только на trim(com1.addr)<>'', т.к. нашим доблестным кадровикам и телефонистам может придти в голову не удалить, а пробелами стереть номер Очевидно, самое простое в моей ситуации - расслабиться и плюнуть, что в отчет строки попадают не отсортированные - отчет в идеале должен быть пустым, ведь номер мобильника может быть привязан только к одному сотруднику