Hi All,
After switched from 3.0.0.32233 to 32266 my app (and IBExpert) give a
string error with the below query, "expected length 124, actual 0".
SELECT COUNT(MON$ATTACHMENTS.MON$ATTACHMENT_ID) FROM MON$ATTACHMENTS
WHERE (MON$SYSTEM_FLAG=0) AND (UPPER(:UN)=MON$USER)
I set :UN to 'A' got 0, 'AA
06.01.2016 1:03, Arno Brinkman wrote:
> Well. this :
>
> SELECT 1 / 3 FROM RDB$DATABASE
> SELECT 1.0 / 3 FROM RDB$DATABASE
>
> should return 0.333, agree ?
Actually, I agree. I believe that division should produce double precision
result.
06.01.2016 8:28, Mark Rottevee
No the scale is implementation dependent with numeric division, however there
is no doubt that in this case it should be handled as integer division.
Mark
- Reply message -
Van: "Dimitry Sibiryakov"
Aan: "For discussion among Firebird Developers"
Onderwerp: [Firebird-devel] Literals in
Gabor Boros wrote Wed, 06 Jan 2016 12:32:31 +0300:
> Hi All,
>
> After switched from 3.0.0.32233 to 32266 my app (and IBExpert) give a
> string error with the below query, "expected length 124, actual 0".
>
> SELECT COUNT(MON$ATTACHMENTS.MON$ATTACHMENT_ID) FROM MON$ATTACHMENTS
> WHERE (MON$SYSTEM
Will look later today...
Em 06/01/2016 12:32, Simonov Denis escreveu:
> Gabor Boros wrote Wed, 06 Jan 2016 12:32:31 +0300:
>
>> Hi All,
>>
>> After switched from 3.0.0.32233 to 32266 my app (and IBExpert) give a
>> string error with the below query, "expected length 124, actual 0".
>>
>> SELECT
Dmitry,
> > In Pavel's use case "color" is a VarChar as such any value/string/variable
> which is assigned to it should be cast as a VarChar, regardless of the
> intermediate datatype.
> >
> > The current outcome is wrong!
>
> The SQL committee respectfully disagrees.
Actually, given that MS SQL
Em 06/01/2016 12:32, Simonov Denis escreveu:
> Gabor Boros wrote Wed, 06 Jan 2016 12:32:31 +0300:
>
>> Hi All,
>>
>> After switched from 3.0.0.32233 to 32266 my app (and IBExpert) give a
>> string error with the below query, "expected length 124, actual 0".
>>
>> SELECT COUNT(MON$ATTACHMENTS.MON$
06.01.2016 19:31, Adriano dos Santos Fernandes wrote:
> No code will ever work correctly with multibyte character sets and CHAR
> (SQL_TEXT) descriptors.
I wonder how it worked since version 2.1?
--
WBR, SD.
--
Fi
Em 06/01/2016 16:37, Dimitry Sibiryakov escreveu:
> 06.01.2016 19:31, Adriano dos Santos Fernandes wrote:
>> No code will ever work correctly with multibyte character sets and CHAR
>> (SQL_TEXT) descriptors.
>
>I wonder how it worked since version 2.1?
>
The bug CORE-5062 is much more deeper
06.01.2016 21:02, Adriano dos Santos Fernandes wrote:
> The bug CORE-5062 is much more deeper than CHAR_TO_UUID and that remains
> unfixed.
I'd suggest you to rollback your "fix" and at first hand to try to remove
check for
exact UUID string length.
--
WBR, SD.
-
On 6-1-2016 21:09, Dimitry Sibiryakov wrote:
> 06.01.2016 21:02, Adriano dos Santos Fernandes wrote:
>> The bug CORE-5062 is much more deeper than CHAR_TO_UUID and that remains
>> unfixed.
>
> I'd suggest you to rollback your "fix" and at first hand to try to remove
> check for
> exact UUID st
Em 06/01/2016 19:08, Mark Rotteveel escreveu:
> On 6-1-2016 21:09, Dimitry Sibiryakov wrote:
>> 06.01.2016 21:02, Adriano dos Santos Fernandes wrote:
>>> The bug CORE-5062 is much more deeper than CHAR_TO_UUID and that remains
>>> unfixed.
>>
>> I'd suggest you to rollback your "fix" and at fir
12 matches
Mail list logo