Вот опять Odac начинает глупости пороть.. ORA-00932

← →
OW © (2011-05-03 12:53) [0]

procedure ReOpenQByTwoDate(Q: TORAQuery; FD, SD: TDate); overload;
begin
Q.Close;
Q.ParamByName("DTF").Value := FD;
Q.ParamByName("DTS").Value := SD;
Q.Open;
Q.First;
end;

..
ReOpenQByTwoDate(oq2, StartOfTheMonth(edtF.Date), edtS.Date);

//EOraError
//ORA-00932: inconsistent datatypes: expected DATE got NUMBER

В прошлый раз тоже самое
Казалось бы, ну где не понятно!?? - нет..
И что главное, ведь работало!
ровно 2 дня, пока не перекомпилил. А теперь пока .Value на .AsDate не заменил, так и не захотел работать.

← →
OW © (2011-05-03 13:02) [1]

А ADO работает

procedure ReOpenQByTwoDate(Q: TADOQuery; FD, SD: TDate); overload;
begin
Q.Close;
Q.Parameters.ParamByName("DTF").Value := FD;
Q.Parameters.ParamByName("DTS").Value := SD;
Q.Open;
end;

← →
Медвежонок Пятачок © (2011-05-03 13:05) [2]

Зачем работать через варианты, если есть типизированные AsString,AsDateTime и т.д.

← →
OW © (2011-05-03 13:26) [3]

Удобнее..

Да просто ладно бы value := неизвестно_что_с_горы
так ведь и StartOfTheMonth типа TDateTime
и потом, когда входной параметр, тоже типа TDate
да и все равно, по-идее Tdate или Number - одно и тоже
а - нет. Не все равно..

← →
sniknik © (2011-05-03 15:44) [4]

> Не все равно..
первоначальная установка типа... в ADO например, если не определен, то будет попытка определения, и значит пройдет, если правильно, а если уже определен то попытка приведения к ...

> когда входной параметр, тоже типа TDate
в ADO такого нет (эээ... да почти ни у кого, не помню ни одного провайдера) только TDateTime, и для даты и для времени монописуально.

p.s. понятно Odac не ADO но... что то общее возможно.

← →
Игорь Шевченко © (2011-05-03 16:53) [5]

> //ORA-00932: inconsistent datatypes: expected DATE got NUMBER

ты хотел чего-то другого, присваивая число с плавающей точкой ?

> Удобнее..

Давить!

← →
OW © (2011-05-03 17:56) [6]

> ты хотел чего-то другого, присваивая число с плавающей точкой
> ?

да, хотел как в процедуре с ADO
и потом, а как ты, не присваивая числа, задашь время?

← →
Игорь Шевченко © (2011-05-03 19:14) [7]

> да, хотел как в процедуре с ADO

если ты хотел, как в процедре с ADO, почему ты не используешь ADO ?

> и потом, а как ты, не присваивая числа, задашь время?

Существует такое свойство у параметра, как AsDateTime.

> Q.ParamByName("DTF").Value := FD;
> Q.ParamByName("DTS").Value := SD;

Какие у тебя типы параметров ? ftUnknown небось ?

← →
sniknik © (2011-05-03 19:15) [8]

> не присваивая числа, задашь время?
никак если "DATE got NUMBER", а "время got дробная часть числа".
поменяй тип в база на аналог "дататайма"/со временем/чисто время (если есть) и вот тогда пожалуйста.

← →
OW © (2011-05-04 08:38) [9]

> Какие у тебя типы параметров ? ftUnknown небось ?

Date

> поменяй тип в база

исключено..

← →
OW © (2011-05-04 09:21) [10]

> Существует такое свойство у параметра, как AsDateTime.

Игорь, читай внимательнее.

> пока .Value на .AsDate не заменил, так и не захотел работать.

т.е. у меня все равботает.

Вообще не знаю зачем спросил. Просто обсудить, наверное.

Просто после
адекватных реакций MSSQL и ADO
сталкиваться со странностью
Oracle и его приближенных (хоть тут, хоть в случае с null||"qq" = "qq")
немного неприятно

← →
sniknik © (2011-05-04 09:27) [11]

ну тогда "приводи" тип, не хочешь через asDateTime то дай в Value ожидаемое им целое число, т.е. вместо
.Value := SD;
сделать типа
iSD: integer; ... iSD:= Trunc(SD); .Value := iSD;

p.s. "удобство" "накроется"

← →
sniknik © (2011-05-04 09:35) [12]

p.p.s. хотя нет, так делать нельзя!...
если передавать просто числом то оно в зависимости от "точки отсчета дат" в для разных субд будет давать разные значения дат после присвоения, при одном и том же числе в исходных... (сравнить к примеру access и mssql)
т.е. тогда будет неопределенность, которая при явном типе даты корректируется провайдером.
в общем, остается единственный вариант.

← →
Кщд (2011-05-04 09:42) [13]

>OW © (04.05.11 09:21) [10]

сталкиваться со странностью
Oracle и его приближенных (хоть тут, хоть в случае с null||"qq" = "qq")

это не "странности", а особенности реализации

> Игорь, читай внимательнее.
>
> > пока .Value на .AsDate не заменил, так и не захотел работать.
>

procedure TParam.SetAsDate(const Value: TDateTime);
begin
FDataType := ftDate;
Self.Value := Value;
end;

Ты уже понял свою ошибку ?

> Просто после
> адекватных реакций MSSQL и ADO
> сталкиваться со странностью
> Oracle и его приближенных (хоть тут, хоть в случае с null||"qq"
> = "qq")
> немного неприятно

Иди в дворники, еще не поздно

> procedure TParam.SetAsDate(const Value: TDateTime);
> begin
> FDataType := ftDate;
> Self.Value := Value;
> end;
>
> Ты уже понял свою ошибку ?

> > Какие у тебя типы параметров ? ftUnknown небось ?
> Date

http://zalil.ru/30975097

OW © (04.05.11 10:40) [15]

у тебя на картинке oq1 а в первом посте oq2

после этого ты хочешь, чтобы я тебе поверил ? ;)
Я тебе специально привел код TParam.SetAsDate, который отличается от твоего присваивания только тем, что принудительно устанавливает тип параметра, а потом делает точно такое же присвоение свойству Value

Работа на свежем воздухе всяко полезнее.

> Игорь Шевченко © (04.05.11 13:27) [16]

> специально привел код TParam.SetAsDate, который отличается
> от твоего присваивания только тем, что принудительно устанавливает
> тип параметра

ну не ужели ты думаешь, что я не понял, для чего ты привел его..
ну так говорю же - ставил, в дизайнере

> у тебя на картинке oq1 а в первом посте oq2

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

хотя.. может и не ставил..
не буду на 100% утверждать. Как доберусь до компа - проверю.
Напишу как было и попробую.

ИШ прав
Не удалось воспроизвести.

скорее всего было так:
не поставил Date в одном из 2х параметров в oq2
потому что фотографической памятью помню - ставил. т.е. так - помню в один из параметров ткнул - стоит. А во втором случае не стал проверять.

Каюсь, грешен,
прицениваюсь к метле :)

Вот опять Odac начинает глупости пороть.. ORA-00932 Найти похожие ветки