mssql2000, простенькая таблица со строковым полем name




пустой набор приходит, если же тупо подставить в like строчку, то все хорошо, возвращает то, что надо.

чего я не знаю о параметрах с like условием?

> пустой набор приходит
а вот не должно бы...
правда с TADOQuery даже проверять не буду.

кстати вспомнил, был глюк в какой то версии дельфей (sp?) с параметром если он стоит последним в строке, попробуй изменить запрос на такой к примеру
select name from table where name like :PName AND 1=1
если сработает значит ты на него, этот глюк, нарвался.

звиняюсь, вопрос снимаю. оказывается для lik'а нужно вручную указывать DataType у параметра, что он ftString. довольно, странно...

> sniknik ©   (07.01.09 13:42) [2]

пробовал. та же ерунда.
вообще странно. но, как уже сказал, тупо указание типа параметра сработывает.

> оказывается для lik'а нужно вручную указывать DataType у параметра
не может такого быть, если параметр ftUnknown а он такой и есть если не смог определится с сервера то тип присваивается по типу варианта входного значения т.е. -> 'стр%' стринг.

посмотри какой тип определился сразу после внесения запроса. ???

уж поверь, я своим глазам верю :)

а я тебе верю, но выяснить что не так разве не интересно?

интересно, вечерком мы вместе с пивом будем это выяснять )

Cлучайно Name не nvarchar?

угу, он самый. самое интересное. у парамера в обоих случаях (и like и просто = (равно) ) DataType есть ftFixedChar (adChar). однако с = присвоение Value корректно отраьатывает, с like же - чепуха. бред какой то... испробовал оба провайдера Native и стандартный... результат ничем не отличается...

а у меня единственная разница в том, что с nvarchar определяет WideString вместо String, но результаты есть в обоих случаях.
и отличие, дельфи у меня 7я я не 6я, а mssql 2000й а не 2005й.

думаю, дело не в версии делфи... adChar тип параметра... а не adVarChar, который по логике быть должен... завтра продолжу, экспиримент на asp проведу... нативней некуда... )

ну я йода мля ) с пда писать себе переписывать дороже )

> Palladin  (07.01.2009 20:28:10)  [10]

Ну тогда я знаю ответ.
В Д6/Д7 nvarchar и еще ряд других функций неправильно работает в параметрах.
Ошибка Борланда с оберткой над АДО.
Решения нет и единственная возможность это переход на Д2006 и выше, там эту ошибку исправили.
Не поможет даже правка генофонда, он просто не компилируется никакими простыми методами.

> В Д6/Д7 nvarchar и еще ряд других функций неправильно работает в параметрах.
у меня D7 и с nvarchar работает правильно...  во всяком случае вот этот конкретный случай ([0] только ADODataSet а не квери)

Я в свое время из-за ошибок в АДО с типами, последовательно переходил с Д5 на Д6, Д7, Д2006 - ошибки касались типов Date/AutoInc/WideString и других. Конечно где какая ошибка устранялась я не помню. Но вот небольшой кусок из Quality Central

http://bdnqc.borland.com/wc/qcmain.aspx?d=8854

касается немного другого вопроса, но Д7 и тот же самый кусок, конечно можно поискать другую ссылку, где говорится, что параметр типа ftWideString возвращался как ftFixedChar. Таких мест несколько. Я проверил свой adodb.pas - у меня исправлен каким то патчем, а у автора статьи еще нет, и у меня тоже самое было на оригинале без патчей.
В 2006 у меня все заработало, с Date/AutoInc/WideString, без патчей. Хотя там еще есть ошибки с АДО, но я с ними не сталкиваюсь.
Неправильные объявления в функциях ADOTypeToFieldType и FieldTypeToADOType

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

> каким то патчем
может TNT ставил (или чего там у них сейчас).

> sniknik  (08.01.2009 17:19:16)  [16]

Может по этому и кажется?
Я привел название двух функций их и нужно проверить.