finally pops bad exception

[jjah...@googlemail.com]

I see from the archives that various people have had this problem,
mainly with MSSQL. But I can't see anywhere that there was any
resolution.

I can't see very far back since my archive search seems to stop about
midway through 2008.

But I get this problem with WindowsXP SP2, python 2.4.4, pyodbc2.1.3.
Database is Pervasive SQL vn 10.10.

If I just use except: and print out sys.exc_info(), I see I get a
pyodbc.ProgrammingError, which is what I am trying to force, but I
cannot trap the exception with except pyodbc.ProgrammingError:

If I try to catch the exception with any option for the exception
class it fails with the pops bad exception message. But the bare
except picks them up.

It could be I am doing something wrong so here is the simple code I
use:

import pyodbc
db = pyodbc.connect('DSN=rocsxda')
cur = db.cursor()
try:
cur.execute("select number,log_status,driver from rcmdri01")
except pyodbc.ProgrammingError:
print 'error'

I have an ODBC trace as well in case it helps. I have included that
below.Unfortunately, I'm no expert on ODBC so I can't really say what
is happening.

Hopefully, someone can point me in the right direction.

Regards

John Aherne


test1 a6c-c90 ENTER SQLSetEnvAttr
SQLHENV 00000000
SQLINTEGER 201 <unknown>
SQLPOINTER [Unknown attribute 201]
SQLINTEGER 4

test1 a6c-c90 EXIT SQLSetEnvAttr with return code 0
(SQL_SUCCESS)
SQLHENV 00000000
SQLINTEGER 201 <unknown>
SQLPOINTER [Unknown attribute 201]
SQLINTEGER 4

test1 a6c-c90 ENTER SQLAllocHandle
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00000000
SQLHANDLE * 1001256C

test1 a6c-c90 EXIT SQLAllocHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00000000
SQLHANDLE * 0x1001256C ( 0x009614f0)

test1 a6c-c90 ENTER SQLSetEnvAttr
SQLHENV 009614F0
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003
SQLINTEGER 4

test1 a6c-c90 EXIT SQLSetEnvAttr with return code 0
(SQL_SUCCESS)
SQLHENV 009614F0
SQLINTEGER 200 <SQL_ATTR_ODBC_VERSION>
SQLPOINTER 0x00000003 (BADMEM)
SQLINTEGER 4

test1 a6c-c90 ENTER SQLAllocHandle
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 009614F0
SQLHANDLE * 0021FCD8

test1 a6c-c90 EXIT SQLAllocHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 009614F0
SQLHANDLE * 0x0021FCD8 ( 0x00961598)

test1 a6c-c90 ENTER SQLDriverConnectW
HDBC 00961598
HWND 00000000
WCHAR * 0x1F7D8BF8 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x1F7D8BF8
SWORD 8
SWORD * 0x00000000
UWORD 0 <SQL_DRIVER_NOPROMPT>

test1 a6c-c90 EXIT SQLDriverConnectW with return code 1
(SQL_SUCCESS_WITH_INFO)
HDBC 00961598
HWND 00000000
WCHAR * 0x1F7D8BF8 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x1F7D8BF8
SWORD 8
SWORD * 0x00000000
UWORD 0 <SQL_DRIVER_NOPROMPT>

DIAG [01000] [Microsoft][ODBC Driver Manager] The driver doesn't
support the version of ODBC behavior that the application requested
(see SQLSetEnvAttr). (0)

DIAG [HYC00] [Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC
Engine Interface]Driver not capable. (0)

test1 a6c-c90 ENTER SQLSetConnectAttr
SQLHDBC 00961598
SQLINTEGER 102 <SQL_ATTR_AUTOCOMMIT>
SQLPOINTER 0x00000000
SQLINTEGER -5

test1 a6c-c90 EXIT SQLSetConnectAttr with return code 0
(SQL_SUCCESS)
SQLHDBC 00961598
SQLINTEGER 102 <SQL_ATTR_AUTOCOMMIT>
SQLPOINTER 0x00000000
SQLINTEGER -5

test1 a6c-c90 ENTER SQLGetInfoW
HDBC 00961598
UWORD 77 <SQL_DRIVER_ODBC_VER>
PTR 0x00962050
SWORD 40
SWORD * 0x0021FC78

test1 a6c-c90 EXIT SQLGetInfoW with return code 0
(SQL_SUCCESS)
HDBC 00961598
UWORD 77 <SQL_DRIVER_ODBC_VER>
PTR 0x00962050 [ 10] "02.50"
SWORD 40
SWORD * 0x0021FC78 (10)

test1 a6c-c90 ENTER SQLGetInfoW
HDBC 00961598
UWORD 10002 <SQL_DESCRIBE_PARAMETER>
PTR 0x00961718
SWORD 4
SWORD * 0x0021FC78

test1 a6c-c90 EXIT SQLGetInfoW with return code 1
(SQL_SUCCESS_WITH_INFO)
HDBC 00961598
UWORD 10002 <SQL_DESCRIBE_PARAMETER>
PTR 0x00961718 [ 4] "ð\ 0"
SWORD 4
SWORD * 0x0021FC78 (10)

DIAG [01004] [Microsoft][ODBC Driver Manager] Data truncated (0)

test1 a6c-c90 ENTER SQLAllocHandle
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 00961598
SQLHANDLE * 0021FC74

test1 a6c-c90 EXIT SQLAllocHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 00961598
SQLHANDLE * 0x0021FC74 ( 0x009624b0)

test1 a6c-c90 ENTER SQLGetTypeInfo
HSTMT 009624B0
SWORD 93 <SQL_TYPE_TIMESTAMP>

test1 a6c-c90 EXIT SQLGetTypeInfo with return code 0
(SQL_SUCCESS)
HSTMT 009624B0
SWORD 93 <SQL_TYPE_TIMESTAMP>

test1 a6c-c90 ENTER SQLFetch
HSTMT 009624B0

test1 a6c-c90 EXIT SQLFetch with return code 0
(SQL_SUCCESS)
HSTMT 009624B0

test1 a6c-c90 ENTER SQLGetData
HSTMT 009624B0
UWORD 3
SWORD 4 <SQL_C_LONG>
PTR <unknown type>
SQLLEN 4
SQLLEN * 0x00000000

test1 a6c-c90 EXIT SQLGetData with return code 0
(SQL_SUCCESS)
HSTMT 009624B0
UWORD 3
SWORD 4 <SQL_C_LONG>
PTR <unknown type>
SQLLEN 4
SQLLEN * 0x00000000

test1 a6c-c90 ENTER SQLFreeStmt
HSTMT 009624B0
UWORD 0 <SQL_CLOSE>

test1 a6c-c90 EXIT SQLFreeStmt with return code 0
(SQL_SUCCESS)
HSTMT 009624B0
UWORD 0 <SQL_CLOSE>

test1 a6c-c90 ENTER SQLAllocHandle
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 00961598
SQLHANDLE * 00A9AE9C

test1 a6c-c90 EXIT SQLAllocHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 00961598
SQLHANDLE * 0x00A9AE9C ( 0x009627c8)

test1 a6c-c90 ENTER SQLFreeStmt
HSTMT 009627C8
UWORD 0 <SQL_CLOSE>

test1 a6c-c90 EXIT SQLFreeStmt with return code 0
(SQL_SUCCESS)
HSTMT 009627C8
UWORD 0 <SQL_CLOSE>

test1 a6c-c90 ENTER SQLExecDirect
HSTMT 009627C8
UCHAR * 0x008C4424 [ -3] "select
number,log_status,driver from rcmdri01\ 0"
SDWORD -3

test1 a6c-c90 EXIT SQLExecDirect with return code -1
(SQL_ERROR)
HSTMT 009627C8
UCHAR * 0x008C4424 [ -3] "select
number,log_status,driver from rcmdri01\ 0"
SDWORD -3

DIAG [42S22] [Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC
Engine Interface]Invalid column name: 'driver'. (0)

DIAG [HY000] [Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC
Engine Interface]Error in expression: driver (0)

test1 a6c-c90 ENTER SQLGetDiagRecW
SQLSMALLINT 3
SQLHANDLE 009627C8
SQLSMALLINT 1
SQLWCHAR * 0x0021F84C (NYI)
SQLINTEGER * 0x0021F898
SQLWCHAR * 0x00963CA0 (NYI)
SQLSMALLINT 1023
SQLSMALLINT * 0x0021F8A8

test1 a6c-c90 EXIT SQLGetDiagRecW with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3
SQLHANDLE 009627C8
SQLSMALLINT 1
SQLWCHAR * 0x0021F84C (NYI)
SQLINTEGER * 0x0021F898 (0)
SQLWCHAR * 0x00963CA0 (NYI)
SQLSMALLINT 1023
SQLSMALLINT * 0x0021F8A8 (103)

test1 a6c-c90 ENTER SQLGetDiagRecW
SQLSMALLINT 3
SQLHANDLE 009627C8
SQLSMALLINT 2
SQLWCHAR * 0x0021F84C (NYI)
SQLINTEGER * 0x0021F898
SQLWCHAR * 0x00963CA0 (NYI)
SQLSMALLINT 1023
SQLSMALLINT * 0x0021F8A8

test1 a6c-c90 EXIT SQLGetDiagRecW with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3
SQLHANDLE 009627C8
SQLSMALLINT 2
SQLWCHAR * 0x0021F84C (NYI)
SQLINTEGER * 0x0021F898 (0)
SQLWCHAR * 0x00963CA0 (NYI)
SQLSMALLINT 1023
SQLSMALLINT * 0x0021F8A8 (101)

test1 a6c-c90 ENTER SQLGetDiagRecW
SQLSMALLINT 3
SQLHANDLE 009627C8
SQLSMALLINT 3
SQLWCHAR * 0x0021F84C (NYI)
SQLINTEGER * 0x0021F898
SQLWCHAR * 0x00963CA0 (NYI)
SQLSMALLINT 1023
SQLSMALLINT * 0x0021F8A8

test1 a6c-c90 EXIT SQLGetDiagRecW with return code 100
(SQL_NO_DATA_FOUND)
SQLSMALLINT 3
SQLHANDLE 009627C8
SQLSMALLINT 3
SQLWCHAR * 0x0021F84C (NYI)
SQLINTEGER * 0x0021F898
SQLWCHAR * 0x00963CA0 (NYI)
SQLSMALLINT 1023
SQLSMALLINT * 0x0021F8A8

test1 a6c-c90 ENTER SQLFreeStmt
HSTMT 009627C8
UWORD 0 <SQL_CLOSE>

test1 a6c-c90 EXIT SQLFreeStmt with return code 0
(SQL_SUCCESS)
HSTMT 009627C8
UWORD 0 <SQL_CLOSE>

test1 a6c-c90 ENTER SQLFreeHandle
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 009627C8

test1 a6c-c90 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 009627C8

test1 a6c-c90 ENTER SQLEndTran
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 00961598
SQLSMALLINT 1

test1 a6c-c90 EXIT SQLEndTran with return code 0
(SQL_SUCCESS)
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 00961598
SQLSMALLINT 1

test1 a6c-c90 ENTER SQLDisconnect
HDBC 00961598

test1 a6c-c90 EXIT SQLDisconnect with return code 0
(SQL_SUCCESS)
HDBC 00961598

test1 a6c-c90 ENTER SQLFreeHandle
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 00961598

test1 a6c-c90 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 00961598

[jjah...@googlemail.com]

Something I omitted from the previous post. I printed out the
exception returned with sys.exc_info().

Now follows:

(<type 'instance'>, <pyodbc.ProgrammingError instance at 0x00A9B580>,
<traceback object at 0x00A9B828>)

Just hoping this will spark off some insight and someone might give me
a clue as to what I should look at next.

John Aherne

On Mar 9, 10:07 am, "jjahe...@googlemail.com"

[Ramiro Morales]

On Mon, Mar 9, 2009 at 8:07 AM, jjah...@googlemail.com
<jjah...@googlemail.com> wrote:
>
> I see from the archives that various people have had this problem,
> mainly with MSSQL. But I can't see anywhere that there was any
> resolution.

See this thread from a couple of months ago about the same issue:

http://groups.google.com/group/pyodbc/browse_frm/thread/997081e53f165003

HTH,

--
Ramiro Morales
http://rmorales.net

[jjah...@googlemail.com]

Thanks for the info.

I did read that thread, but misread it as more related to sqlobject
than the problem I was having.

However, I upgraded to 2.5.4 and the problem has gone away.

But the exception from sys.exc_info() I get with 2.5.4 has a lot more
stuff in it. Copy below as reference for anyone else seeing this
problem.

Thanks for the feedback.

John Aherne


(<class 'pyodbc.ProgrammingError'>, ProgrammingError('42S22', "[42S22]

[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine
Interface]

Invalid column name: 'driver'. (0) (SQLExecDirectW); [HY000]

[Pervasive]
[ODBC Client Interface][LNA][Pervasive][ODBC Engine Interface]Error
in expression:

driver (0)"), <traceback object at 0x00A8C058>)

On Mar 9, 10:07 pm, Ramiro Morales <cra...@gmail.com> wrote:
> On Mon, Mar 9, 2009 at 8:07 AM, jjahe...@googlemail.com

[mkleehammer]

Issue 40 has been opened for this. The reported issue was that the
exception could not be caught, but it turns out to be the same thing:

http://code.google.com/p/pyodbc/issues/detail?id=40

I have been swamped for about 3 months, but I'll try to fix as many
open issues as possible this weekend.

This particular issue has to do with how the exception is being set in
the C code -- what I am doing seems correct according to the
documentation and Python source, but clearly it isn't what Python 2.4
expects. Python 2.5 and 2.6, however, work as expected. (And as you
can guess, I work in Python 2.6 mostly.)

I will try to figure out how to set exception information in a way
that 2.4 likes.

As a separate issue, I highly recommend upgrading to 2.6 if possible.
I've found the new additions invaluable. I realize this is difficult
on many Linux distros that use 2.4 internally.

[jjah...@googlemail.com]

Thanks for the response.

I appreciate the help and the time it takes. So if you can get a fix,
I shall be very pleased.

Thanks Again.

John Aherne

[mkleehammer]

Fixed in f98eac65ce01ccac56711293ade0c30d4c4fa39d, which will be in
2.1.5 as soon as
I release it.

Apparently *neither* solution was correct by itself -- you have to
sometimes use
in_class and sometimes the type. Python 2.6 has
PyExceptionInstance_Class exactly
for this. Since we also build for 2.4 I simply did the same thing the
macro does.