Done.
And here is a second oddity, that I'd say is a bug. For preparation consider the following simple table with one entry.
Create table a (a varchar(5), b varchar(10)); insert into a values ('12345','1234567890');
Now, the following statement outputs, as expected, 1234567890:
SELECT CASE WHEN 1=2 THEN a ELSE b END from a;
Result: 1234567890
However, when putting in a constant value then MonetDb returns an odd result:
SELECT CASE WHEN 1=2 THEN a ELSE 'lala' END from a;
Result: Px?~
The result is even varying if you run the query multiple times.
Does anybody have any ideas on this one?
Regards, Arno
----- Ursprüngliche Mail ----- Von: "Sjoerd Mullender" sjoerd@acm.org An: "users-list" users-list@monetdb.org Gesendet: Mittwoch, 24. Februar 2016 16:16:09 Betreff: Re: Typecasting in prepared statements
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Either you have a problem with your locale settings, or this is a bug in MonetDB. Since I can reproduce the problem, I fear it's the latter. Can you please submit a bu report at bugs.monetdb.org? Thanks.
On 24/02/16 16:10, Arno Mittelbach wrote:
Hi all,
I am having a strange problem regarding prepared queries with Umlaute (e.g., ä). It seems that the rule for type casting strings correspond to the length of the string. The problem is that an Umlaut seems to count for two "normal" characters. Here is an example. Consider the following simple table:
create table A (a varchar(4));
Now if we create a prepared statement (ultimately I want to do this from Java) such as
prepare select * from A where a = ?;
we can execute the statement and supply 4 characters as the argument:
exec 3('1234');
This works fine. However, if I am using an Umlaut within the parameter, then things don't work out. For example
exec 4('ä123');
fails with the following error message
EXEC: wrong type for argument 1 of prepared statement: char, expected varchar
However, if I now shorten the parameter by "1" character, it works again. That is,
exec 5('ä12');
is ok.
Can anybody explain this behavior? Is this a bug? And is there a workaround? The only thing I came up with so far is to double the size of every column.
Best regards,
Arno
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
- -- Sjoerd Mullender
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list