Hi Лисонька!

1) Если в tab2 будет 10 записей с одним и тем-же кодом, и в tab1 будет 10 записей с этим кодом - то при запросе типа
в выборку попадут не 10 "подходящих", а 100 - т.е. каждая нужная запись повторится 10 раз. соответственно если будет по 100 "дублей", то получим уже 10000 записей в результате!
Эта неприятность не случилась бы, если бы cDelNomer в tab2 был уникален (т.е. одно значение не повторялось в нескольких записях).
Но конечно лучше запрос с IN (SELECT ... ) использовать.
2) "Задумался" он и упал в конце концов, потому что у тебя чересчур много дублей было в таблице. В самом "страшном" случае - если бы ВСЕ записи обеих таблиц содержали одно и то-же значение в полях связи, в результате твоего запроса должна была-бы образоваться выборка размером примерно в 26 Гигабайт (20000*82000*17 - где 17 это размер одной записи новой выборки - я предполагаю что nID имеет тип Integer - т.е. 4 байта+12 байт+1 на признак удаления). Фокс не может производить выборок размером более 2 Гб (ограничение на размер dbf действует и на "временные" курсоры). Для превышения этого лимита в принципе достаточно чтобы в первой и второй таблице было хотя-бы по 12000 записей с идентичным значением полей связи (например ПУСТЫМИ полями cRegNomer и cDelNomer)
3) Сравнение Tab1.cRegNomer # " " - не совсем корректно - если поле имеет размер C(12) то и выражение для сравнения должно быть размером 12 символов, ИЛИ должна действовать установка SET ANSI ON (тогда фокс сам дополнит более короткую строку до длинны второй строки), ИЛИ нужно использовать сравнение == что аналогично "местному" применению SET ANSI ON (т.е. тогда условие будет выглядеть как [src]!(Tab1.cRegNomer == " ")[src]). В целом ряде случаев может помочь и банальное !EMPTY() - главное не забывать, что "пустое" это и пробел и TAB и перевод строки... Если поле не "бинарное" то обычно это не критично.
Указанное сравнение же даст .T. и в случае когда cRegNomer = " 123" и для cRegNomer = " ABC"... И вообще всех тех где только ПЕРВЫЙ символ поля есть пробел.
4) Чтобы получать пользу (и удовольствие) от SQL запросов необходимо подумать про оптимизатор - обеспечить его нужными индексами. В данном случае - нужны индексы по этим символьным полям.

Posted via ActualForum NNTP Server 1.3