Date: 2016-07-01 12:06:34 +0200
From: homner
To: SQL devs <>
Version: 11.23.3 (Jun2016)

Last updated: 2016-07-22 09:56:08 +0200

Comment 22223

Date: 2016-07-01 12:06:34 +0200
From: homner

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Build Identifier:

After update to the latest version, the odbc driver show no decimal places but
with the montdb user the decimal places are shown.
With mclient, in both cases (monetdb, myuser) the decimal places are shown

Reproducible: Always

Steps to Reproduce:

1. CREATE TABLE eis.test5(turnover numeric(18,6));
2. INSERT into eis.test5 VALUES(1234.56);
3. SELECT turnover from eis.test5

Actual Results:

1234

Expected Results:

1234.560000

Comment 22224

Date: 2016-07-04 17:36:46 +0200
From: @sjoerdmullender

I can't reproduce this.

What program are you using to interact through ODBC with the MonetDB server?
Is this a program you wrote? If so, can you share the source?

Comment 22225

Date: 2016-07-05 09:42:44 +0200
From: homner

OK, here a simple VBScript

dim cn, rs

set cn = CreateObject("ADODB.Connection")
set rs = CreateObject("ADODB.Recordset")
cn.connectionstring = "DSN=mydb;Uid=monetdb;Pwd=monetdb"
cn.open
rs.open "SELECT freight FROM myschema.orders LIMIT 1", cn, 3
wscript.echo "MonetDB User"

while not rs.eof
wscript.echo rs(0)
rs.MoveNext
wend
cn.close

wscript.echo ""

cn.connectionstring = "DSN=mydb;Uid=myuser;Pwd=*********"
cn.open
rs.open "SELECT freight FROM myschema.orders LIMIT 1", cn, 3
wscript.echo "Other User"

while not rs.eof
wscript.echo rs(0)
rs.MoveNext
wend
cn.close

Here the output:

Microsoft (R) Windows Script Host, Version 5.8
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

MonetDB User
32,38

Other User
32

Additional information:
There is a different in the tcp stream, the monetdb user received in the meta data part:
18 6 typesizes

----------------------------MonetDB User--------------------------------------------
..!.Xreply_size 100
..e.sSET TIME ZONE INTERVAL '+01:00' HOUR TO MINUTE
;
..&3
..sselect name, value from sys.env() where name in ('monet_version', 'gdk_dbname')
;
9.&1 0 2 2 2
% .L, .L table_name
% name, value name
% varchar, varchar type
% 13, 7 length
[ "gdk_dbname", "mydb" ]
[ "monet_version", "11.23.3" ]
..Xsizeheader 1
..!.Xreply_size 100
..U.sSELECT freight FROM myschema.orders LIMIT 1
;
..&1 1 1 1 1
% myschema.orders table_name
% freight name
% decimal type
% 20 length
% 18 6 typesizes
[ 32.380000 ]

----------------------------Other User ------------------------------------

..!.Xreply_size 100
..e.sSET TIME ZONE INTERVAL '+01:00' HOUR TO MINUTE
;
..&3
..sselect name, value from sys.env() where name in ('monet_version', 'gdk_dbname')
;
A.!SELECT: no such operator 'env'
!.Xreply_size 100
..U.sSELECT freight FROM myschema.orders LIMIT 1
;
..&1 0 1 1 1
% myschema.orders table_name
% freight name
% decimal type
% 20 length
[ 32.380000 ]

Comment 22226

Date: 2016-07-05 12:41:28 +0200
From: @sjoerdmullender

I now understand what the cause is.
We added permissions (grants) to functions, and there is a grant missing for calling sys.env() by users other than the administrator (monetdb). The ODBC driver calls this function to find out the version of the server which it needs to decide whether the server is new enough so that it understands the request to send the typesizes header.
Since the introduction of that request is so long ago, we can remove that check, but the driver still needs the version number for other, more recent changes in the server.
Whether a fix for this will be in the SP1, I don't know yet. I have just created a release candidate, but I could decide to create a second release candidate after this is fixed.

Comment 22227

Date: 2016-07-05 13:21:00 +0200
From: MonetDB Mercurial Repository <>

Changeset 0e52ba88168c made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

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

Changeset description:

Don't check for server version number when we can work around it.
The check in SQLConnect was for such an old version that we can remove
it, the check in SQLTables we could work around in the SQL query.
This (actually the SQLConnect part) should fix bug #4032.

Comment 22232

Date: 2016-07-05 16:29:58 +0200
From: @sjoerdmullender

This should be fixed now.