ORAselectПоправь имя курсора везде MyCursor. Пользуйся запросами везде, где можно. А можно везде. Не втыкай явные циклы, не используй replace... и не придется пробелы считать, думать как и что сравнивать. Изучи команды SQL - поможет наперед!!!
Для поиска одной записи использовать Select-SQL? Можно, конечно, но это называется "из пушки по воробьям". "Использовать везде, где можно" - слишком категорично. Получишь массу проблем и тормозов. Как ни странно, но Select-SQL далеко не всегда самый быстрый способ поиска данных.

Вообще-то, самый первый ответ от Guest1000 - самый правильный. Вместо перебора следует использовать команду LOCATE

ORAselectНадо уметь им пользоватться, в т.ч. индексами.
Золотые слова! Я серьезно.

Только почему Вы применяете их выборочно? Для Select-SQL: "учитесь пользоваться", а для всех остальных команд поиска: "прошлый век", "поезд ушел"?

Если рассматривать команду Select-SQL, то, в общем случае:

1) Сложнее для понимания. Как следствие, кличество ошибок больше . Сложнее в отладке. Накосячить тоже есть где. Не в синтаксисе, а именно в логике.

Например, Вы уже накосячили даже в такой примитивной задаче. Ошибочная логика. Вас подвела именно кажущаяся простота. Как собственно задачи, так и конструкции Select-SQL.

Точнее, не то, чтобы "накосячили", а сделали ряд допущений, при которых такая логика будет работать. Но не спросили автора топика, а действительно ли у него заданы эта граничные условия? В данном случае:

-) SET ANSI (возможен ли поиск по первым символам?)
-) Может ли быть для разных Login один и тот же Password (где проверка Login?)
-) Уже не по Select-SQL: использовать PUBLIC для локальных задач - получить большие проблемы

2) Есть ряд задач, когда Select-SQL работает значительно медленнее навигационных команд

3) Если речь идет о таблицах, объем записей которых невелик (не думаю, что список пользователй так уж огромен), то разница в скорости команд Select-SQL и навигационных команд не ощутима. Как для программы, так и для пользователя


Для справки :

ВСЕ команды FoxPro имеющие опцию FOR также используют Rushmore-оптимизацию. Для полного ее использования рекомендуется перед такими командами отключать главнй индекс (SET ORDER TO 0). В этом случае скорость работы таких команд сопоставима со скоростью SEEK.

ORAselect
В итоге есть задача, а она на самом деле достаточно тривиальна и проста. Делать туманные представления о возможных проблемах там, где их нет не вижу смысла и опыт (более 20 лет) показал, что именно SQL наиболее полно соответствует именно сложным программам с внушительной логикой.
В данном случае использование Select-SQL усложняет и затуманивает решение задачи. Зачем мне подсчитывать количество , если надо найти одну единственную запись? Любую.

ORAselectА переход на работу в СУБД ORACLE и совсем привел к мысли, что там, где есть выбор между SQL и чем угодно еще нужно выбирать SQL.
Не совсем так. В данном случае это привело к лености мысли.

У Вас есть две среды разработки: Хранилище данных (в данном случае ORACLE) и FoxPro.

Каждая среда предполагает определенную идеологию работы. Это означает, что надо постоянно "переключаться" с одной идеологии на другую. Это сложно и трудно. А поскольку FoxPro позволяет использовать Select-SQL, то для простоты Вы сделали вывод: надо везде использовать одинаковые команды. Это проще . Для Вас.

Но это вовсе не означает, что это проще на самом деле.

ORAselectСобственно, это показала мировая практика и тут Ваше мнение вряд ли что изменит.
После такого заявления, обычно предлагается привести "явки и пароли". Знаете ли, после советского воспитания, я слабо верю лозунгам и призывам типа: Я, как и весь трудовой народ... Говори за себя, а "весь трудовой народ" еще неизвестно как думает Как мне кажется, это вовсе не "мировая практика", а Ваше личное мнение.

ORAselectВо-вторых. Явно пишет новичек и именно ему, а не Вам я дал вполне ответственный совет.
Вот именно! Если Вы даете какой-то совет, то аргументируйте его! ПОЧЕМУ надо делать именно так, а не иначе? А лозунги, они лозунги и есть. Рассчитаны не на знание, а на эмоции.

ORAselectВ третьих. И Вам советую применять SQL везде, где можно. Попрактикуете и наверняка согласитесь. Я тоже лет 10 назад подписался бы под вашим ответом.
Применять инструмент надо по назначению . Расхожий штамп: микроскопом гвозди забивать. Ведь можно же! Почему не забивают?

Ну нет никаких аргументов в данном случае в пользу Select-SQL. Не дает он здесь никакого выигрыша. Ни в чем. Ни в понимании, ни в простоте, ни в скорости. Усложение есть, а упрощения - нет.