Здравствуйте, Мастера!
Прошу прощения за тривиальный вопрос.
Обычно я использую таблицу или запрос, и тогда быстрый поиск можно делать по индексу функцией FindKey, к примеру.
Сейчас хочу создать форму-Lookup - своего рода шаблон с гридом, чтобы показывать данные, возможность выбрать нужную запись и закрыть форму. При открытии формы (как вариант) надо становиться на запись по заданному значению ключа (если значение ключа передано как параметр, к примеру). Вот как то так.
Поскольку этот шаблон я буду использовать для таблиц TadsTable, а также запросов TadsQuery, то думаю, что правильнее для работы с данными на форме использовать  TDataSet. Но, только уж очень медленно работает Locate.
1.Я читала на форуме, что некоторые программисты вообще Locate не используют. А что в таком случае?
2.А может вообще идея насчет использовать TDataSet в моем случае не самый оптимальный вариант?
3.И еще, почему то в XE8 Locate с опцией loCaseInsensitive у меня не работает, выбает ошибку AV. В версии D2007 работает нормально. Пока я могу использовать без этой опции, но хотелось бы узнать, это XE версии баг или что то только у меня?
Хотелось бы услышать коммертарии на все три вопроса.
(Для уточнения, работаю с Advantage).
Заранее спасибо!

> очень медленно работает Locate.
Locate тоже использует индекс, если он есть, если нет то перебором. т.е. чуть более универсально чем FindKey. а вот то что медленно... как напишешь, с учетом специфики используемого, от функций обычно не зависит.

> что некоторые программисты вообще Locate не используют.
некоторые и дельфи не используют, не нужен он им... и что же в таком случае?

> А может вообще идея насчет использовать TDataSet в моем случае не самый оптимальный вариант?
оптимальность "в вакууме" это вообще миф, для одного действия что-то оптимально для другого нет. зависит от того, что ты делаешь в "твоем случае". хотя в принципе датасет для обработки данных вполне оптимален.

> почему то в XE8 Locate с опцией loCaseInsensitive у меня не работает, выбает ошибку AV. В версии D2007 работает нормально.
чисто предположительно, причина в тебе конечно, как написал, но и в юникоде еще, раз один и тот же код без его поддержки работает, с поддержкой -ошибка. его ты не учел.

> работаю с Advantage
важное уточнение, он вроде еще файл-сервер? т.е. напрямую с таблицей работает? тогда если таблица в расшарке то наскорость работы влияет сеть, Locate перечитывает файл при переборе, и т.д. у всего свои особенности.

> [1] sniknik ©   (13.01.17 10:11)
> важное уточнение, он вроде еще файл-сервер?

Там два варианта файл серверный и клиент серверный.

> [0] Abcdef123 ©   (13.01.17 09:21)
> я буду использовать для таблиц TadsTable, а также запросов
> TadsQuery, то думаю, что правильнее для работы с данными
> на форме использовать  TDataSet

Что за ерунда? TAdsTable и есть потомок TDataSet. Идеологически в Advantage TAdsTable как раз и подойдёт для выбора из справочника в гриде. Locate вполне себе нормальный метод, только индексы необходимые должны быть для скорости. Ну и кроме того есть более явный поиск по индексу как у TAdsTable, так и у TAdsQuery
AdsSeek
В TAdsQuery можно после открытия создать необходимые индексы. В случае файл серверного доступа stADS_LOCAL, физически выборка и индексы будут расположены для ускорения в локальной папке %TEMP%.

Из справки

CAUTION The AdsSeek method is not any slower nor any less efficient than the native Delphi equivalent FindKey and FindNearest methods. But in nearly every single situation, the native Delphi methods FindKey and FindNearest are easier to use. It is recommended that the Advantage extended method AdsSeek only be used when absolutely necessary. See your Delphi documentation for more information about the FindKey and FindNearest Delphi methods.

> Там два варианта файл серверный и клиент серверный.
ну тогда +
еще там (в его компонентах) должно быть что то типа клиентского датасета (получать данные с сервера на клиент и обработка локально), с возможностью создать локальный индекс и т.д. ну как обычно у компонент для клиент-сервера. в общем еще больше особенностей, и зависимостей от того как используется.

> [5] sniknik ©   (13.01.17 11:01)

Ну я выше написал про TAdsQuery. Это всё прозрачно работает, я сервером не пользовался, но достаточно поменять метод доступа, и должно всё стать клиент-серверным "теоретически".
Два наследника всего, что для локального, что для серверного одни и те же TAdsTable и TAdsQuery. Причём TAdsTable не есть что-то неправильное.

To [1] >Locate тоже использует индекс, если он есть, если нет то перебором. т.е. чуть более универсально чем FindKey. а вот то что медленно... как напишешь, с учетом специфики используемого, от функций обычно не зависит.
Вы имеете в виду физический индекс в таблице? Он есть, Locate искользую именно по этому полю, но все равно медленно.
> чисто предположительно, причина в тебе конечно, как написал, но и в юникоде еще, раз один и тот же код без его поддержки работает, с поддержкой -ошибка. его ты не учел.
Я думала, что в юникоде дело, поэтому значение ключа как Locate параметр прописываю как Вариант значение, хотя поле в таблице строковое. А как правильно надо?

To [6]. Так я ничего не имею против TAdsTable и TAdsQuery. Просто в данном примере, если рассматривать форму как шаблон с передаваемым параметром данных могут быть 2 варианта (TAdsTable и TAdsQuery), как я в таком случае на форме должна оперировать-различать?

Различать можно

> [8] Abcdef123 ©   (13.01.17 12:29)
> как я в таком случае на форме должна оперировать-различать?

Для поиска с помощью Locate различать не надо - метод есть и там и там.

Если медленно, значит всё-таки индекс не задействован. Попробуй для начала проще сделать - с TAdsTable - и посмотреть на скорость поиска. Насчёт AV потом разобраться - должно нормально работать.

Как индекс создан?

> Вы имеете в виду физический индекс в таблице?
я имею ввиду существующий... даже если он есть физический, в таблице, но ты сделал запрос в клиент-серверном стиле, то на клиент придут "голые" данные, индексы останутся на сервере, т.е. не будут существовать без их создания уже локально (если поддерживается компонентами).

> параметр прописываю как Вариант значение
вариант это не тип, это "контейнер" разных типов, типа универсально, но на самом деле зависит от реализации. я бы лучше использовал тип AnsiString (или преобразование к нему), хотя опять же, зависит в каком виде данные у в таблице... может нужно наоборот.

> А как правильно надо?
не бывает правильно "в вакууме", только применительно к чему то, причем попытка перенести на другое тут же делает его неправильным.

И сразу ещё вопросы.
Таблицы какие - родные для Ads ADT, FoxPro CDX, VPF или может Clipper NTX?
И какая кодовая страница?

to [13] Таблицы FoxPro CDX, коды OEM

> коды OEM
вах

> я бы лучше использовал тип AnsiString
беру свой слов обратн.

... хотя ..., компоненты преобразование делают?

> [14] Abcdef123 ©   (13.01.17 15:39)

Понятно. А индекс как создан?
Индексное выражение какое?

> [15] sniknik ©   (13.01.17 15:47)
> компоненты преобразование делают?

Делают

Ещё на всякий случай, хоть на скорость поиска это и не должно влиять. В файле
adslocal.cfg
есть такие строчки?
ANSI_CHAR_SET=Russian
OEM_CHAR_SET=RUSSIAN

и файлы
ansi.chr
extend.chr

и вообще все файлы быблиотеки 10 штук из специально для этого имеющейся паки Redistribute должны быть расположены в путях поиска и быть одной версии ADS. Для проверки стоит попробовать поместить из одного комплекта установки, который и используется в работе, в самый ближайший путь - в папку с исполняемым файлом программы. Мало ли как там и где что раскидано.

to [16] Index  выражение -просто название поля , поле типа String?