Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.08.05;
Скачать: [xml.tar.bz2];

Вниз

Поиск в базе, чувствительный к регистру   Найти похожие ветки 

 
Jungle   (2002-07-12 11:28) [0]

Как бы осуществить Partial поиск (без SQL), чувствительный к регистру, в ADOTable. Через Locate не получается. Т.е. если есть запись со значением "amZ", а пишешь
Locate("Key", "amz", [loPartialKey]) - он устанавливается на эту запись, а не должен бы по идее...
В чем дело? Не подскажете как с этим бороться?


 
Johnmen   (2002-07-12 11:38) [1]

Сканируй НД сам.


 
Jungle   (2002-07-12 11:46) [2]

Я тут поглядел на твои ответы.
Если следовать твоим советам, так нужно писать собственный движок и компоненты для работы с БД.


 
Johnmen   (2002-07-12 11:51) [3]

На основании каких моих ответов сделан такой вывод ???? :)
Или ты ожидаешь, что я приведу сразу кусок работающего кода ?
:)))))))))))


 
Anatoly Podgoretsky   (2002-07-12 11:55) [4]

Jungle © (12.07.02 11:46)
И что тут такого, если стандартное поведение не нравится и есть жедание, почему бы не написать, а может лучше изменить подход к написанию, что бы делать в рамках стандартных возможностей.
Не беда Джонов, что им приходится отвечать на подобные вопросы.


 
Jungle   (2002-07-12 12:05) [5]

Значит так.
1. Я не отношусь к разработчикам средств разработки.
2. У меня не настолько крутая задача, чтобы наживать лишний геморрой на свою голову :)
3. Я не ожидаю, чтобы мне приводили куски кода. Мне интересно, существует ли СТАНДАРТНЫЙ способ (готовая функция или процедура), осуществляющая описанные действия. Может, нужно где-то какой-то параметр изменить. Или это связано с самой базой. (Я с базами работал постольку-поскольку, поэтому не шибко шарю во всяких тонкостях).


 
Johnmen   (2002-07-12 12:11) [6]

>Jungle ©

1. Я тоже к ним не отношусь
2.
3. Нет

>Я не отношусь к разработчикам средств разработки

Это здесь непричем ! Просто напиши цикл обхода НД, в котором осуществляется проверка значения нужного поля на то, что надо.


 
Jungle   (2002-07-12 12:21) [7]

Я его уже давно написал. И хотя все коротко и цивильно, и даже правильно работает :), все равно - изврат.
Чем больше стандартных функций (если они удовлетворяют требованиям задачи) - тем лучше.
А нестандартными компонентами не пользуюсь из принципа - случись чего (потеряется или т.п.) - задолбаешься из д..ма откапываться...


 
Johnmen   (2002-07-12 12:36) [8]

>Jungle © (12.07.02 12:21)
>Чем больше стандартных функций (если они удовлетворяют
>требованиям задачи) - тем лучше.

Ты можешь написать письмо Борланду, типа, "что это ты, засранец, заставляешь меня занималься извратом и писать прогу ? я хочу складывать ее из изготовленных тобой кирпичиков ! и не париться с выдумыванием своих алгоритмов и приемов..."

А где же творческое начало ?



 
Jungle   (2002-07-12 12:52) [9]

Понимаешь ли, согласись с одним фактом.
Если в опциях к Locate есть параметр LoCaseInsensitive, значит подразумевается, что без него поиск должен быть чувствительным к регистру - не так ли?
А насчет творческого начала вот что. Можно ведь и с кучей крутых компонентов написать полную лажу (правда и со стандартными тоже). Все дело в том - как наиболее рациональным способом (с наименьшим количеством кода и проблем) достичь максимального эффекта (быстродействие, безглючность и т.п.). Творческий подход как раз в этом и заключается - эффективно и рационально использовать предлагаемые тебе средства.
Если брать стандартные компоненты, то с большой долей уверенности можно ожидать (все-таки Delphi - продукт серьезный), что твое творение будет нормально работать на разных конфигурациях компьютеров (если только сам не лажанешься). А вот если брать "левые" (особенно бесплатные), то в совершенно непредсказуемый момент может проявиться черт знает что.


 
Johnmen   (2002-07-12 13:23) [10]

Ну правильно говоришь...
Вот разве что я сейчас попробовал
Locate("...",...,[loPartialKey]);

ВСЕ РАБОТАЕТ КАК ОЖИДАЛОСЬ!!!


 
Jungle   (2002-07-12 13:59) [11]

Ну и какие соображения? В чем может быть дело? Поверь, я просто так, без попыток докопаться до сути, писать бы не стал. Да и не дурак, вроде...
Ты с ADOTable пробовал, с Access"овской базюкой? Если да, то я ничего не понимаю...


 
Johnmen   (2002-07-12 14:19) [12]

Нет, я пробовал с IBDataSet"ом с IB"ишной базой.
Есть предположение, что это баг в ADO....



 
Jungle   (2002-07-12 14:25) [13]

Вот только если баг...
Слушай, а с фильтром работал?

Я пишу:
Filter := "Key = " + QuotedStr(LabeledEdit1.Text+"*");
Filtered := true;

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

Может это я чего-то неправильно делаю?


 
Johnmen   (2002-07-12 14:34) [14]

В выражении фильтра маска недопустима.


 
Jungle   (2002-07-12 14:46) [15]

Вообще-то можно. Вот цитата из Хелпа (Setting the Filter Property):
* wildcard for partial comparisons (FilterOptions must include foPartialCompare)
Правда, foPartialCompare не существует для ADOTable.
Но суть в том, что и без * фильтр не работает. Это я уж от безысходности ее туда воткнул...


 
Johnmen   (2002-07-12 14:57) [16]

Удивительно ! Может еще один баг ?
А ты лучше скачай апдейт для ADO и посмотри, что будет.
Где качать - не помню, поищи - найдешь !


 
Jungle   (2002-07-12 15:09) [17]

Опасно... Я щас отлаживаю коммерческую прогу (не ту, в которой Locate), мало ли чего случится...
Да... Ну и дела...


 
sniknik   (2002-07-12 20:33) [18]

CaseSensitive не поддерживается в ADO (я проверил) при подключении к Access, Dbf через Jet и через ODBC (только для dbf проверял) а также наверно и в других случаях, т.к. упоминания о loCaseInsensitive я не нашол в модуле ADODB в частности в процедуре TCustomADODataSet.LocateRecord (чего там ожидалось если бы работало).
по аналогии с TBDEDataSet.LocateRecord (где есть и работает)
можно с претензиями к борланду обращатся (если бы легальное по юзали :-)
p.s. апдейтил ADO совсем недавно, думаю у меня последняя версия на сегодня.


 
Anatoly Podgoretsky   (2002-07-12 20:40) [19]

Jungle © (12.07.02 14:25)
Кажется что ты пытаешься работать с АДО как с БДЕ парадокс/дбейс таблицами, вроде бы для Акцесс другии ограничители, не буду конечно утверждать, но в любом случае тебе нужен зелп не по Дельфи, а по Акцессу и конечно ставить апдейт обязательно, что очень важно для коммерческой программы, он устраняет некоторые ошибки, ты с ними еще столкнешься,


 
sniknik   (2002-07-12 20:53) [20]

Кстати мне идея в голову стукнула. Самый простой путь как написать свой Locate.
запоминаеш состояние таблици (Букмарк)
вызываеш стандартный Locate
проверяеш в зависимости от ключа loCaseInsensitive совпадение строки и ключа поиска.
не подходит откат.

быстрей будет чем циклы по таблице гонять.


 
Jungle   (2002-07-15 08:06) [21]

Я так и делаю, только Букмарк не использую...


 
roottim   (2002-07-15 10:53) [22]

Все верно!.. адо не держит case для Jet
пришла одна мысль(непроверял),
а что если воспользоваться методом Seek из _Recordset!


 
Jungle   (2002-07-15 11:55) [23]

Что за дела!
Закрываю таблицу.
Пишу IndexName="Key"
Открываю таблицу - OLE Error.
Мозги пухнут уже...



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.08.05;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.5 MB
Время: 0.004 c
1-13597
Kolya
2002-07-22 21:29
2002.08.05
Pause Process


14-13787
restless
2002-07-10 13:10
2002.08.05
Чем Delphi лучше С или С++


8-13734
Злой
2002-03-27 12:30
2002.08.05
Приветствую!!! Не подскажите как осуществить такую идею оздаю список из mp3 файлов и


1-13648
c0pYc@t
2002-07-23 10:28
2002.08.05
Глупый вопрос


1-13698
hm
2002-07-23 21:55
2002.08.05
Icon





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский