pyodbc: ERROR: No results. Previous SQL was not a query.

Environment

To diagnose, we usually need to know the following, including version numbers. On Windows, be sure to specify 32-bit Python or 64-bit:

  • Python: 3.9
  • pyodbc: 4.0.26
  • OS: <AWS Lambda environment>
  • DB: SQL Server
  • driver: ODBC Driver 17 for SQL Server

Issue

We have multiple users in the SQL database and we want to reset the password for some users by using master user login, but when we try to reset the password using the lambda function, it is showing the error as “ERROR: No results. The previous SQL was not a query.” but other SQL statements(Select or Insert) are working as expected rather “ALTER

Here is a code sample:

import json
import pyodbc

def lambda_handler(event, context):
    try:
        pyodbc.pooling = False
        conn = pyodbc.connect('Driver={ODBC Driver 17 for SQL Server};Server=amazon-rd-endpoint,1433;Database=database_name;Uid=supper_user;Pwd=password;CENSORED;Trusted_Connection=yes;',autocommit=True)
        cursor = conn.cursor()
        
        cursor.execute("ALTER LOGIN second_user WITH PASSWORD = 'newPassword'")
        conn.commit()

        return {
            'statusCode': 200,
        }
    except Exception as e:
        print('ERROR: ', e)

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (6 by maintainers)

Most upvoted comments

The error comes from line 100 here:

https://github.com/mkleehammer/pyodbc/blob/24e0ccadaec091ce6b1b81e3197a345b895773fc/src/cursor.cpp

…so Cursor_Validate needs to be called with at least CURSOR_REQUIRE_RESULTS and CURSOR_RAISE_ERROR for that to occur. Where does that happen?

  • Cursor_iternext
  • Cursor_fetchval
  • Cursor_fetchone
  • Cursor_fetchall
  • Cursor_fetchmany
  • Cursor_skip

…none of which are called from Cursor_execute, so the error you are getting in this issue is practically impossible given the code you claim to be executing.

I am not sure what you are trying to say. In any case, neither me nor Gord are able to reproduce your issue. What did you expect? The previous SQL was indeed not a query.