Uploaded image for project: 'MariaDB Connector/ODBC'
  1. MariaDB Connector/ODBC
  2. ODBC-169

Empty results or error if executing mutliple selects in a batch

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 3.0.6
    • 3.0.7, 2.0.19
    • General
    • None
    • Server: FreeBSD 10.3 , MariaDB 10.3.8 Client: Windows 10, ODBC 3.0.6

    Description

      Might still be a problem with the parsing of the batch.

      All examples are executed as a single batch:

      Example one:

      select 1;
      		 
      select 1;

      This does deliver the right results.

      Example two:

      SELECT * from DB.mytable;
      		 
      SELECT 1;

      This does deliver all the rows from mytable and the 1 at the end. Works.

      Example three:

      SELECT 1;
      		 
      SELECT * FROM DB.mytable;

      This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

      Example four:

      SELECT * FROM DB.mytable;
      		 
      SELECT * FROM DB.mytable;

      The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException. Fields with INT datatype do work somehow.

      A similar result with data from the information_schema is returned by these queries:

      CREATE TEMPORARY TABLE _temp_statistics  AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
      		 
      SELECT * FROM _temp_statistics;

      or

      DROP TABLE IF EXISTS _temp_statistics;
      		 
      SELECT * FROM INFORMATION_SCHEMA.STATISTICS;

      These statements do work with the mysql ODBC driver or executed on their own.

      Attachments

        Issue Links

          includes

          Bug - A problem which impairs or prevents the functions of the product. ODBC-203 Empty results if executing mutliple selects in a batch

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. ODBC-247 Multiple batches via .NET gives AccessViolationException

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            Patrick Dudziak Patrick Dudziak created issue -
            Patrick Dudziak Patrick Dudziak made changes -
            Field Original Value New Value
            Description Might still be a problem with the parsing of the Batch.

            All Examples are executed as a single Batch:

            Example one:
            {{select 1;
            select 1;}}

            This does deliver the right results.

            Example two:
            {{SELECT * from DB.mytable;
            SELECT 1;}}

            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:
            {{SELECT 1;
            SELECT * FROM DB.mytable;}}

            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:
            {{SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            }}
            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException.

            A similar result with data from the information_schema is returned by these queries:
            {{CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "´DB");
            SELECT * FROM _temp_statistics;}}

            These statements do work with the mysql ODBC driver or executed on their own.
            		Might still be a problem with the parsing of the Batch.

            All Examples are executed as a single Batch:

            Example one:

            {code:java}
            select 1;
            select 1;
            {code}


            This does deliver the right results.

            Example two:

            {code:java}
            SELECT * from DB.mytable;
            SELECT 1;
            {code}


            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:

            {code:java}
            SELECT 1;
            SELECT * FROM DB.mytable;
            {code}


            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:

            {code:java}
            SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            {code}


            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException.

            A similar result with data from the information_schema is returned by these queries:

            {code:java}
            CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
            SELECT * FROM _temp_statistics;
            {code}


            These statements do work with the mysql ODBC driver or executed on their own.
            Patrick Dudziak Patrick Dudziak made changes -
            Description Might still be a problem with the parsing of the Batch.

            All Examples are executed as a single Batch:

            Example one:

            {code:java}
            select 1;
            select 1;
            {code}


            This does deliver the right results.

            Example two:

            {code:java}
            SELECT * from DB.mytable;
            SELECT 1;
            {code}


            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:

            {code:java}
            SELECT 1;
            SELECT * FROM DB.mytable;
            {code}


            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:

            {code:java}
            SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            {code}


            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException.

            A similar result with data from the information_schema is returned by these queries:

            {code:java}
            CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
            SELECT * FROM _temp_statistics;
            {code}


            These statements do work with the mysql ODBC driver or executed on their own.
            		Might still be a problem with the parsing of the batch.

            All examples are executed as a single batch:

            Example one:

            {code:java}
            select 1;
            select 1;
            {code}


            This does deliver the right results.

            Example two:

            {code:java}
            SELECT * from DB.mytable;
            SELECT 1;
            {code}


            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:

            {code:java}
            SELECT 1;
            SELECT * FROM DB.mytable;
            {code}


            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:

            {code:java}
            SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            {code}


            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException.

            A similar result with data from the information_schema is returned by these queries:

            {code:java}
            CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
            SELECT * FROM _temp_statistics;
            {code}


            These statements do work with the mysql ODBC driver or executed on their own.
            Patrick Dudziak Patrick Dudziak made changes -
            Description Might still be a problem with the parsing of the batch.

            All examples are executed as a single batch:

            Example one:

            {code:java}
            select 1;
            select 1;
            {code}


            This does deliver the right results.

            Example two:

            {code:java}
            SELECT * from DB.mytable;
            SELECT 1;
            {code}


            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:

            {code:java}
            SELECT 1;
            SELECT * FROM DB.mytable;
            {code}


            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:

            {code:java}
            SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            {code}


            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException.

            A similar result with data from the information_schema is returned by these queries:

            {code:java}
            CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
            SELECT * FROM _temp_statistics;
            {code}


            These statements do work with the mysql ODBC driver or executed on their own.
            		Might still be a problem with the parsing of the batch.

            All examples are executed as a single batch:

            Example one:

            {code:java}
            select 1;
            select 1;
            {code}


            This does deliver the right results.

            Example two:

            {code:java}
            SELECT * from DB.mytable;
            SELECT 1;
            {code}


            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:

            {code:java}
            SELECT 1;
            SELECT * FROM DB.mytable;
            {code}


            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:

            {code:java}
            SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            {code}


            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException. Fields with INT datatype do work somehow.

            A similar result with data from the information_schema is returned by these queries:

            {code:java}
            CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
            SELECT * FROM _temp_statistics;
            {code}


            These statements do work with the mysql ODBC driver or executed on their own.
            Patrick Dudziak Patrick Dudziak made changes -
            Description Might still be a problem with the parsing of the batch.

            All examples are executed as a single batch:

            Example one:

            {code:java}
            select 1;
            select 1;
            {code}


            This does deliver the right results.

            Example two:

            {code:java}
            SELECT * from DB.mytable;
            SELECT 1;
            {code}


            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:

            {code:java}
            SELECT 1;
            SELECT * FROM DB.mytable;
            {code}


            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:

            {code:java}
            SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            {code}


            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException. Fields with INT datatype do work somehow.

            A similar result with data from the information_schema is returned by these queries:

            {code:java}
            CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
            SELECT * FROM _temp_statistics;
            {code}


            These statements do work with the mysql ODBC driver or executed on their own.
            		Might still be a problem with the parsing of the batch.

            All examples are executed as a single batch:

            Example one:

            {code:java}
            select 1;
            select 1;
            {code}


            This does deliver the right results.

            Example two:

            {code:java}
            SELECT * from DB.mytable;
            SELECT 1;
            {code}


            This does deliver all the rows from mytable and the 1 at the end. Works.

            Example three:

            {code:java}
            SELECT 1;
            SELECT * FROM DB.mytable;
            {code}


            This does deliver the first result "1" and after that a "AccessViolationException" gets returned.

            Example four:

            {code:java}
            SELECT * FROM DB.mytable;
            SELECT * FROM DB.mytable;
            {code}


            The first SELECT delivers the right results, but the 2nd SELECT returns only the correct amount of rows but they are empty and trigger a NumberFormatException. Fields with INT datatype do work somehow.

            A similar result with data from the information_schema is returned by these queries:

            {code:java}
            CREATE TEMPORARY TABLE _temp_statistics AS (SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = "DB");
            SELECT * FROM _temp_statistics;
            {code}

            or

            {code:java}
            DROP TABLE IF EXISTS _temp_statistics;
            SELECT * FROM INFORMATION_SCHEMA.STATISTICS;
            {code}


            These statements do work with the mysql ODBC driver or executed on their own.
            Lawrin Lawrin Novitsky added a comment -

            Well, I am pretty much sure this is not parsing issue in this case. Also, I believe we have tests covering multiple resultsets case. There must be something more to that. I'd appreciate, if you could provide ODBC traces for those failing examples.

            I didn't quite understand what is the problem with last two queries - one from your previous bug report and from I_S table. They both have only 1 SELECT statement. And it does not work in both cases? Well, I will extend the testcase for the previous bug report, and see if there are problem to read select results.

            Lawrin Lawrin Novitsky added a comment - Well, I am pretty much sure this is not parsing issue in this case. Also, I believe we have tests covering multiple resultsets case. There must be something more to that. I'd appreciate, if you could provide ODBC traces for those failing examples. I didn't quite understand what is the problem with last two queries - one from your previous bug report and from I_S table. They both have only 1 SELECT statement. And it does not work in both cases? Well, I will extend the testcase for the previous bug report, and see if there are problem to read select results.
            Patrick Dudziak Patrick Dudziak made changes -
            Attachment Test5.LOG [ 46017 ]
            Attachment Test6.LOG [ 46018 ]
            Attachment Test1.LOG [ 46019 ]
            Attachment Test2.LOG [ 46020 ]
            Attachment Test3.LOG [ 46021 ]
            Patrick Dudziak Patrick Dudziak made changes -
            Attachment Test5.LOG [ 46017 ]
            Patrick Dudziak Patrick Dudziak made changes -
            Attachment Test3.LOG [ 46021 ]
            Patrick Dudziak Patrick Dudziak made changes -
            Attachment Test2.LOG [ 46020 ]
            Patrick Dudziak Patrick Dudziak made changes -
            Attachment Test6.LOG [ 46018 ]
            Patrick Dudziak Patrick Dudziak made changes -
            Attachment Test1.LOG [ 46019 ]
            Patrick Dudziak Patrick Dudziak made changes -
            Attachment Traces.zip [ 46022 ]
            Patrick Dudziak Patrick Dudziak added a comment -

            I attached a zip with traces for all 6 examples provided. And yes the last two queries both are not working, even with only 1 select, but they do contain 2 queries excecuted in a single batch.

            As always thank you for help.

            Patrick Dudziak Patrick Dudziak added a comment - I attached a zip with traces for all 6 examples provided. And yes the last two queries both are not working, even with only 1 select, but they do contain 2 queries excecuted in a single batch. As always thank you for help.
            Lawrin Lawrin Novitsky added a comment -

            And as always - thank you for your reports!

            Lawrin Lawrin Novitsky added a comment - And as always - thank you for your reports!
            Lawrin Lawrin Novitsky made changes -
            Fix Version/s 3.0.7 [ 23145 ]
            Fix Version/s 2.0.19 [ 23200 ]
            Lawrin Lawrin Novitsky made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Lawrin Lawrin Novitsky added a comment - - edited

            I've fixed problem causing 3 and 4. Yet to be pushed, though.

            I've noticed your reply, and that I already asked this very same question

            Lawrin Lawrin Novitsky added a comment - - edited I've fixed problem causing 3 and 4. Yet to be pushed, though. I've noticed your reply, and that I already asked this very same question
            Lawrin Lawrin Novitsky added a comment -

            The fix and the testcase have been pushed to odbc-3.0 as bfb78c0

            Lawrin Lawrin Novitsky added a comment - The fix and the testcase have been pushed to odbc-3.0 as bfb78c0
            Lawrin Lawrin Novitsky made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Closed [ 6 ]
            Patrick Dudziak Patrick Dudziak made changes -
            willshak Kristian Wedberg made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 88792 ] MariaDB v4 [ 135480 ]

            People

              Lawrin Lawrin Novitsky
              Patrick Dudziak Patrick Dudziak
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.