Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong typecast on character columns in prepared statements when using Umlaute #3930

monetdb-team opened this issue Nov 30, 2020 · 0 comments


Copy link

@monetdb-team monetdb-team commented Nov 30, 2020

Date: 2016-02-24 17:02:08 +0100
From: Arno Mittelbach <<arno.mittelbach>>
To: SQL devs <>
Version: 11.21.13 (Jul2015-SP2)

Last updated: 2016-03-25 09:59:12 +0100

Comment 21818

Date: 2016-02-24 17:02:08 +0100
From: Arno Mittelbach <<arno.mittelbach>>

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Build Identifier:

There seems to be 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.

Reproducible: Always

Steps to Reproduce:

  1. create table A (a varchar(4));
  2. prepare select * from A where a = ?;
  3. exec 2('ä123');

Actual Results:

EXEC: wrong type for argument 1 of prepared statement: char, expected varchar

Expected Results:

No error

Comment 21824

Date: 2016-02-25 17:36:57 +0100
From: MonetDB Mercurial Repository <>

Changeset 58c81fe1e454 made by Sjoerd Mullender in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=58c81fe1e454

Changeset description:

When parsing a string in SQL, record the number of Unicode code points, not bytes.
This fixes bug #3930.
Also added test.

Comment 21828

Date: 2016-02-26 14:49:06 +0100
From: @sjoerdmullender

Fixed by counting properly.

Comment 21956

Date: 2016-03-25 09:59:12 +0100
From: @sjoerdmullender

Jul2015-SP3 has been released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant