JDBC driver: incorrect output result of SQL query: SELECT 1 ; #3471
Last updated: 2014-10-31 14:13:39 +0100
Date: 2014-04-11 17:57:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
it outputs 49 instead of 1
Steps to Reproduce:
Query: SELECT 1 AS wrong1, 2 AS wrong2, 3 AS wrong3, 4 AS wrong4, 9 AS wrong9, 10 AS wrong10, 99 AS wrong99, 0 AS wrong0, -1 AS wrong_1;
Query: SELECT -1 AS wrong1, -2 AS wrong2, -3 AS wrong3, -4 AS wrong4, -9 AS wrong9, -10 AS wrong10, -99 AS wrong99, -0 AS wrong0;
So the output numbers increase (to 57) and decrease (to 45).
Date: 2014-04-11 20:03:55 +0200
I'm unable to repeat this bug. Anymore details on how to reproduce?
Date: 2014-04-13 12:54:11 +0200
Just FYI, I can't reproduce it neither (MonetDB v11.17.14).
Date: 2014-04-13 13:51:25 +0200
Same here, i.e., all works fine with Jan2014-SP1 on my 64-bit Fedora 20 laptop:
Date: 2014-04-13 15:07:41 +0200
I saw Martin van Dinther's GUI client (SQuirreL?) displaying wrong results like he reported.
@martin van Dinther: would you please check if your monetdb server is giving wrong results by execute your queries using e.g. mclient?
Date: 2014-04-13 15:30:26 +0200
Aha --- the original bug report did not mention Squirrel ... ;-)
well, then it seems like that for some reason Squirrel shows the ASCII codes of the single-character numbers (character '1' has ASCII code 49) than the numbers themselves ...
Date: 2014-04-18 17:24:54 +0200
So there is a difference is in the column data type meta data.
I checked java/src/nl/cwi/monetdb/jdbc/MonetResultSet.java for method:
I will have to write a small Java program (testing getShort(), getInt() and getString()) to find out where it goes wrong in the fetching method. Will do that later.
Date: 2014-04-18 19:01:42 +0200
Have written a small Java program testing getShort(), getInt() and getString() with the test_tinyint table. No issues found for these methods.
However using the method getByte() produced the same results as SQuirreL.
We have currently implemented in MonetResultSet.java
As we transfer data as Strings, the getByte() takes the String value and if not empty converts it to bytes array and returns the first byte.
Date: 2014-05-09 19:11:49 +0200
I have created a fix for it and tested it succesfully.
Tried to check in the fix into branch Jan2014, but got:
Date: 2014-05-09 21:14:41 +0200
This it not the complete Mercurial error message.
"(pull and merge or see "hg help push" for details about pushing new heads)"
Please do NOT considere the second option, i.e., forcing push to push new heads!
The reason for the error message is that apparently there are new remote changes in the branch that you committed to locally and now want to push to.
To resolve the situation, you first need to pull the new remote changes.
hg pull --rebase
This command will rebase your local commits on top of the incoming changesets. This means that you don't need to create a separate changeset to merge your changes with the incoming changes.
To enable the rebase extensions, add the following to your configuration file:
In case you did already pull the new remote changes without "--rebase", you will have to merge the two heads (the one you created locally, and the one created remotely) using
For general and very useful information and guidelines about (using) Mercurial, please consult https://www.monetdb.org/Assets/MonetDB-Mercurial.html
In fact, the entire document is considered "mandatory literature" for any/all MonetDB developer(s); this includes studying the document and following advice given!
Date: 2014-05-16 16:09:49 +0200
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=2ccadb9bd115
Date: 2014-06-30 14:20:08 +0200
*** Bug #3503 has been marked as a duplicate of this bug. ***
Date: 2014-10-31 14:13:39 +0100
Oct2014 has been released.
The text was updated successfully, but these errors were encountered: