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

Different answer from querys in the ODBC compared to mcliente or other DBMSs #2981

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


Copy link

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

Date: 2012-01-19 17:36:03 +0100
From: Luiz Gustavo de Souza <<luiz.souza>>
To: clients devs <>
Version: 11.5.9 (Aug2011-SP3) [obsolete]

Last updated: 2012-01-26 15:32:05 +0100

Comment 16793

Date: 2012-01-19 17:36:03 +0100
From: Luiz Gustavo de Souza <<luiz.souza>>

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Build Identifier: Embarcadero RAD Studio XE Version 15.0.3953.35171

I got some queries that return different results in my application using Delphi and ODBC, compared to the mclient and from a copy of the DB in PostgreSQL. Apparently I can have the correct answer if I put a NULL column in SELECT, like

"SELECT Col01, NULL FROM Table01;"

But still my BI application have a different behaviour in the result of the queries compared to PostgreSQL. I ran separately the queries in mclient and the Postgres's PgAdmin, and there the results were the same.

Reproducible: Always

Steps to Reproduce:

1.Running the following query in an application with Delphi
2.SELECT 2001 as Ano;

Actual Results:

(NOTE: My application can't retrieve the data, giving a lot of errors)

Expected Results:


  1. now run the following query
  2. SELECT 2001 as Ano, NULL;
  3. You'll get the following result, which is:
    2001 | NULL

Comment 16794

Date: 2012-01-19 17:38:00 +0100
From: Luiz Gustavo de Souza <<luiz.souza>>

Created attachment 97
log from my application run, but apparently no errors are found from the queries.

Attached file: odbc.log (application/octet-stream, 131090 bytes)
Description: log from my application run, but apparently no errors are found from the queries.

Comment 16796

Date: 2012-01-19 18:32:02 +0100
From: Luiz Gustavo de Souza <<luiz.souza>>

I ran over the bug. I put a NULL column in all the queries and the application worked.

Comment 16798

Date: 2012-01-20 10:20:26 +0100
From: @sjoerdmullender

I don't see a correlation in the log with the queries that you mention in your report. Can you create a log where you try the queries you mention?

Comment 16799

Date: 2012-01-20 11:03:30 +0100
From: Luiz Gustavo de Souza <<luiz.souza>>

I'm attaching the log with the exact queries I mentioned on the report.

Comment 16800

Date: 2012-01-20 11:03:53 +0100
From: Luiz Gustavo de Souza <<luiz.souza>>

Created attachment 98
Log with the report queries

Attached file: odbc.log (application/octet-stream, 4021 bytes)
Description: Log with the report queries

Comment 16801

Date: 2012-01-20 13:47:54 +0100
From: @sjoerdmullender

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

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

Changeset description:

ODBC: Use correct row descriptor when returning values in SQLFetch.
SQLFetch can return information about the fetched data to the
application through the SQL_ATTR_ROW_STATUS_PTR and
SQL_ATTR_ROWS_FETCHED_PTR statement attributes.  These values are
stored in the Implementation Row Descriptor, not in the Application
Row Descriptor.

This should fix bug #2981.

Comment 16802

Date: 2012-01-20 14:05:22 +0100
From: @sjoerdmullender

Hopefully fixed.
The fix is in the Dec2011 branch and will be in the next release.

Comment 16829

Date: 2012-01-26 15:32:05 +0100
From: @sjoerdmullender

The Dec2011 version has been release, so declaring this bug as FIXED.

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