db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edson Carlos Ericksson Richter <edson.rich...@mgrinformatica.com.br>
Subject Re: ERROR 42X89: Types 'INTEGER' and 'CHAR' are not type compatible. Neither type is assignable to the other type.
Date Fri, 28 Jul 2006 15:57:07 GMT
IMHO, any data type could be automatically treated as null (and null 
should be automatically cast to any data type - depending only on 
expression context), and your CASE expression is fine (analyzing the 
syntax, is just correct).
So, it's a Derby bug, of course, and should be fixed ASAP (but it's only 
MHO).

I have several multi-database applications, and is very weird having 3 
or more versions of each report just because some database need some 
casting (like this case), or don't accept some kind of join.
To have one idea, any report using MaxDB and aggregate functions that 
returns decimals, need to start the expression with 1.0*(the expression) 
or you will be out of decimals in your report. This occur since SapDB 
days, and was never :( fixed  - this is just an example I know (there is 
lot's more on MaxDB product), and is the reason we don't support MaxDB 
any more in our software...

Derby, in general, don't show this weird behaviors, but your case 
expression made me re-evaluate all my reports to check if I'm not going 
to show wrong results to my customers due to this bug.


Regards,

Richter



Peterson, John escreveu:
> Our concern with casting NULL to the appropriate type is that it might
> have a performance impact on the other databases.  At this point it
> appears as though we would have to do performance testing of our
> software on all supported databases to determine if the impact of the
> CAST is worth supporting Derby as well.  However, if this is a bug which
> will be fixed in a future release our efforts will be for naught.
> Clearly it would be preferable if we could avoid expending our resources
> on adapting and testing code which currently already works.  We are
> trying to assess whether the Derby community considers this issue a bug
> before making our decision about whether or not our software will
> support Derby.
>
> Thanks,
> John 
>   


Mime
View raw message