|
Гадский Locate и пр. методы поиска
|
||
|---|---|---|
Участник
Откуда: Москва (Муром)
Сообщения: 78 075 |
||
| 25.02.2003, 15:01 |
|
|
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Гадский Locate и пр. методы поиска
|
|||
|---|---|---|---|
|
#18+
Добрый день всем! Вопрос уже задавал, но очень уже допекает.... База VFP, доступ через ADO (OLEDB for ODBC). Делаю: Код: plaintext Код: plaintext Ибо, запись эта есть, но с совершенно др. RecNo. Пробую Seek - провайдер не поддерживает. Хотя в ADO такой метод есть. Пробую Filter, пробую через ADO Find - тоже самое. Не делает различий между регистрами. А между тем, rn - primary key. Хочется понять, это такая особенность Delphi/ADO/VFP или мой личный глюк? И как тогда вообще можно найти запись по ее первичному ключу??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2003, 14:53 |
|
||
|
Гадский Locate и пр. методы поиска
|
|||
|---|---|---|---|
|
#18+
А зачем тебе RecNo, ведь если запись нашлась, то она становиться текущей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2003, 15:01 |
|
||
|
Гадский Locate и пр. методы поиска
|
|||
|---|---|---|---|
|
#18+
Особенность или глюк не важно, не должно быть такого... Я бы плюнул и начал бы искать обходные пути, например, если длина ключа строго ограничена создать вычисляемое поле: Код: plaintext и искать по нему... Конечно, будет работать медленнее, но ведь будет! Или можно так: Код: plaintext 1. 2. 3. Не проверял... Я думаю "делфийское" сравнение строк (в данном случае <>) не различает регистр. Кстати, надо убедится, что сами FieldValues[] приходят в исходном регистре... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2003, 15:30 |
|
||
|
Гадский Locate и пр. методы поиска
|
|||
|---|---|---|---|
|
#18+
> pkarklin RecNo мне не нужен. он для примера. Дело в том, что в обоих случаях находится одна и таже (первая) запись, хотя на самом деле записи разные - у значения поля "rn" различается регистр. > m_kus Дельфийское сравнение регистр различает. Фильтр работает также, т.е. тоже не работает. А обходные пути - сводятся к циклу while not ADOTable1.Eof do begin ... if Value = ADOTable1.FieldByName(...).AsString then ... end Но, думаю, это существенно медленнее чем Locate. А для меня это критично. Вычисляемое поле - так ведь все равно искать не по индексу, не как Locate Вот ведь напасть - и PK есть, и искать не получается. Если только "select ..." формировать? - дак тоже ведь медленнооооо будет! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2003, 15:57 |
|
||
|
Гадский Locate и пр. методы поиска
|
|||
|---|---|---|---|
|
#18+
Да, я и хотел сказать - различает регистр... :) Что до фильтра, так ведь он вернёт только несколько записей, по ним то уже циклом пройти не так долго, я так понимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2003, 16:28 |
|
||
|
Гадский Locate и пр. методы поиска
|
|||
|---|---|---|---|
|
#18+
> m_kus Это идея... Вот ведь изврат - по PK делать фильтрацию и искать циклом! Осталось только проверить - насколько быстро будет фильтрация по PK для 10 тыщ. записей.... Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2003, 17:18 |
|
||
|
|
start [/forum/topic.php?fid=58&msg=32110909&tid=2119050]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
136ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 457ms |
| 0 / 0 |
