Ah, now I understand what you mean that an empty table can explain the
difference between index and non-index.
But I still don't understand why the explicit cast solves the problem, even
when that is the same type and character set as the parameter already has.
Mark
- Reply message -
Va
07.01.2016 19:44, Mark Rotteveel wrote:
> That comment makes no sense. If there is no index it also needs to be
> evaluated. It then uses NATURAL instead of an index access to find the
> record(s) (or no records).
If the natural scan returns no rows, then WHERE conditions are not
evaluated. For
07.01.2016 15:56, Adriano dos Santos Fernandes wrote:
>> Remember that a CAST(? as CHAR(10) CHARACTER SET OCTETS) is described in
> I mean CAST(? as CHAR(10) CHARACTER SET UTF8)...
You (and currently engine too) mix up data size in bytes and count of
characters in a
string.
xsqlvar.sqllen
On 07/01/2016 12:53, Adriano dos Santos Fernandes wrote:
> Remember that a CAST(? as CHAR(10) CHARACTER SET OCTETS) is described in
I mean CAST(? as CHAR(10) CHARACTER SET UTF8)...
Adriano
--
Firebird-Devel mailing lis
On 07/01/2016 12:44, Dimitry Sibiryakov wrote:
> 07.01.2016 15:27, Adriano dos Santos Fernandes wrote:
>> Now imagine the client passing this:
>>
>> SQL_TEXT
>> length: 40
>> charset: utf-8
>> data: 1234567890<30 spaces>
>>
>> What char_length should return?
>40. Because the data indeed contain
Mark,
CHAR_TO_UUID is a very special function as it declares how it wants to
receive its parameter based in nothing else.
Now imagine this, when user connects with UTF-8:
select char_length(?) from rdb$database;
That is not valid because the parameter has no type, but suppose it's
valid. Now im
On Wed, 6 Jan 2016 21:59:53 -0200, Adriano dos Santos Fernandes
wrote:
>> I have one concern though, as I indicated in the ticket the problem
>> **only** occurs if the UUID column (a char(16) octets) has an index. If
>> the field doesn't have an index, the error does not occur with the
exact
>>
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
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
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.
-
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 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 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$
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
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
15 matches
Mail list logo
