Ошибка при поиске

← →
Ренат (2004-01-15 11:39) [0]

Пишу кусок
if IBTable4.Locate("streetnm;districtid",VarArrayOf([ul,disid]),[])

типы данных совпадают.
Выдается ошибка Cannot transliterate ... В чем м.б. дело?
подскажите

← →
Flagman (2004-01-15 11:43) [1]

Полагаю COLLATE

← →
Vlad (2004-01-15 11:44) [2]

http://www.ibase.ru/devinfo/ibrusfaq.htm

← →
Term (2004-01-15 11:45) [3]

не вдаваясь в подробности, не используй TIBTable тупиковый путь.
Возьми сразу TIBDataSet и осваивай его

← →
Ренат (2004-01-15 11:46) [4]

ладно буду ковырять

← →
Vlad (2004-01-15 11:49) [5]

> Ренат © (15.01.04 11:46) [4]
> ладно буду ковырять

Совет: начни "ковыряние" с того, что пропиши в IBDatabase.params
строчку:
lc_ctype=win1251

← →
Flagman (2004-01-15 11:55) [6]

2 Term

И если на то пошло лучше юзать FibPlus

← →
Term (2004-01-15 11:57) [7]

>2 Flagman © (15.01.04 11:55) [6]

я это сказал к тому, чтобы он не пытался работать с IB навигационным методом, а не о том какие компаненты круче :)))

← →
Vlad (2004-01-15 12:00) [8]

> Term © (15.01.04 11:57) [7]

Locate - вполне навигационный метод. И почему же с ним нельзя работать в IB ?

← →
Flagman (2004-01-15 12:02) [9]

2 Vlad

Работать можно... Только медленно и печально... ;)

← →
Vlad (2004-01-15 12:04) [10]

> Flagman © (15.01.04 12:02) [9]

Насчет мелденно - согласен. Но это лечится - не делай больших наборов данных на клиенте. Насчет печально - не согласен. Зачастую очень удобная и нужная функция.

← →
Term (2004-01-15 12:09) [11]

> Vlad © (15.01.04 12:00) [8]

вот именно > Flagman © (15.01.04 12:02) [9]
всё так и есть, ведь всё относительно, если у него в таблице мильён записей и по ней Locate делать ... работать то конечно будет но... ничего хорошего от такой работы разработчику не скажут :))) Да к тому же TIBTable обращается к таблице вот так:
select * from Table
то и трафик будет офигенный, и ваще эти компаненты были введены для совместимости с БДЕ, так что это можно сказать атавизмы

← →
Flagman (2004-01-15 12:13) [12]

2 Vlad
"Медленно и печально" - это из анекдота...
Если набор данных небольшой, то да... А если большой?
Я в таких случаях использую конструкцию типа
Flg=DATABASE.QueryValue("Select Count(ID) From Table1 Where ...",0);
if (Flg=1) then ...
else...

Работает быстрее чем Locate, причем по всей таблице.

← →
Vlad (2004-01-15 12:19) [13]

> Flagman © (15.01.04 12:13) [12]

Ну да, а представь что у тебя есть задача динамически позиционироваться на строки в DBGrid, в зависимости от набираемых пользователем клавишей ? Как ты эту задачу решишь ?

← →
Term (2004-01-15 12:22) [14]

> Vlad © (15.01.04 12:19) [13]

опять же не используя TIBTable, чо хош только не TIBTable, почему написанно выше :)))

← →
Flagman (2004-01-15 12:22) [15]

2 Vlad

Юзай TDBGridEh из EhLib

Там эта задача давно решена, причем хорошо оформлена визуально.

← →
Vlad (2004-01-15 12:26) [16]

> Term © (15.01.04 12:22) [14]

Да причем тут TIBTable ?
Ты сказал, что нЕфига использовать навигационные методы в IB.
Я тебе привел пример, где без них не обойтись. В любом наборе данных, не обязательно TIBTable.

> Flagman © (15.01.04 12:22) [15]

Угу, только там используются те же навигационные методы. Смысл его использовать для этого ?

← →
Johnmen (2004-01-15 12:28) [17]

>Flagman © (15.01.04 12:22)

Странно... На прямой четкий вопрос Vlad © (15.01.04 12:19)
нет ответа. А только бесполезный совет не относящийся к делу...

← →
Term (2004-01-15 12:34) [18]

> Ты сказал, что нЕфига использовать навигационные методы
> в IB.

всё верно, токо я еще сказал что всё относительно, под относительно понимается объём возвращаемого набора данных, если не большой, то пожалста Locate, я ж не ставлю вопрос кардинально

← →
Vlad (2004-01-15 12:41) [19]

> Term © (15.01.04 12:34) [18]

В этом все и дело.
В мире все относительно :-)

← →
Flagman (2004-01-15 12:42) [20]

>Угу, только там используются те же навигационные методы. Смысл его использовать для этого ?

Насчет скорости правда не уверен, в исходниках не рылся, но хотя бы потому, что сократится количество собственного кода.

>нет ответа. А только бесполезный совет не относящийся к делу...

Это и был ответ...
А вот ветка действительно ушла... :))

← →
Vlad (2004-01-15 12:48) [21]

> Flagman © (15.01.04 12:42) [20]
> >Угу, только там используются те же навигационные методы.
> Смысл его использовать для этого ?
>
> Насчет скорости правда не уверен, в исходниках не рылся,
> но хотя бы потому, что сократится количество собственного
> кода.

Как раз это - не есть ответ на поставленный вопрос :-)
Буду премного благодарен, если ты найдешь ответ, как же не используя навигационные методы решить вышеупомянутую задачу :-)

← →
Term (2004-01-15 12:52) [22]

ветка ушла в том смысле, что разговор ушёл в сторону от того вопроса КОТОРЫЙ ЗАДАЛ АВТОР :))))

← →
Ренат (2004-01-15 13:26) [23]

Почему TIBTable тупиковый путь?

← →
Johnmen (2004-01-15 13:33) [24]

>Почему TIBTable тупиковый путь?

Потому, что ведет в тупик...:)))

← →
Vlad (2004-01-15 13:35) [25]

> Ренат © (15.01.04 13:26) [23]

Да не то что бы совсем тупиковый, просто для современных SQL-серверов предусмотренны гораздо более мощные методы работы чем позволяет TIBTable. А она, как говорят, оставлена в IB лишь для более удобного перехода с BDE, но использовать ее практически смысла не имеет.

← →
Sandman25 (2004-01-15 13:38) [26]

+ в IBTable куча багов, уже не помню, каких именно :)

← →
Ренат (2004-01-15 13:39) [27]

> Потому, что ведет в тупик...:)))

логично, но не хотелось бы таких комментариев

← →
Vlad (2004-01-15 13:39) [28]

> Sandman25 © (15.01.04 13:38) [26]

Кстати тоже самое когда-то слышал про БДЕ-шный TTable (правда только слышал, реально не натыкался)

← →
Johnmen (2004-01-15 13:43) [29]

← →
Sandman25 (2004-01-15 13:44) [30]

[28] Vlad © (15.01.04 13:39)

Смотря с какой СУБД работать. У меня с Paradox вроде работает без багов.
А вот с IB вроде бы действительно недавно на форуме был обнаружен очередной баг.

← →
Vlad (2004-01-15 13:47) [31]

Но кстати, IBTable - похоже, единственный выход для тех кто не дружит (или не хочет дружить по религиозным соображениям, итд.) с SQL :-)

← →
Sandman25 (2004-01-15 13:48) [32]

← →
Academic (2004-01-15 14:42) [33]

Ну скажите наконец, почему же возникает ошибка.
Не Нулевой результат поиска, а именно ошибка???

← →
Vlad (2004-01-15 14:56) [34]

В IB-датасетах свой собственный метод Locate (не унаследованный от TDataSet). Если поля, по которым происходит поиск индексированы в таблицах, то Locate использует этот индекс. Отсюда вывод - разные кодировки таблицы на сервере и клиентского запроса.

← →
Academic (2004-01-15 15:01) [35]

> Vlad © (15.01.04 14:56)

> таблицы на сервере и клиентского запроса.

1.Используется TIBTable а не запрос.
2.В Случае различия кодировок, ошибка прявила бы себя раньше.

← →
Term (2004-01-15 15:04) [36]

> 1.Используется TIBTable а не запрос

а он при подключении обращается к базе с запросом:
SELECT * FROM Table
так что.....

← →
Academic (2004-01-15 15:12) [37]

> Term © (15.01.04 15:04)

Все компоненты доступа так или иначе общаются с помощью запросов.
Это известно. Но объясните мне какая кодировка может быть у "запроса". Кодировка указывается для драйвера при коннекте к базе данных.

← →
Vlad (2004-01-15 17:11) [38]

Вобщем, трудно сказать, возможно это и есть тот глюк, о котором говорил Sandman25 ©
Автору: попробуй ради эксперимента простой цикл
while not IBTable1.Eof do IBTable1.Next;
Ошибка будет или нет ?

Ошибка при поиске Найти похожие ветки