Re: [INTERFACES] ODBC - MSysConf - Mailing list pgsql-interfaces
From | David Hartwig |
---|---|
Subject | Re: [INTERFACES] ODBC - MSysConf |
Date | |
Msg-id | 36C43B28.41546578@insightdist.com Whole thread Raw |
In response to | ODBC - MSysConf (Karsten Kaus <kk@kdschmid.de>) |
List | pgsql-interfaces |
What version of the PostgreSQL driver are you running? What version of Access? What version of the Driver Manager? The driver install will upgrade to the DM to 3.0 but it is optional. I probably should have asked this before we got this far. Karsten Kaus wrote: > > MSACCESS fff27265:fff26281 ENTER SQLExecDirect > HSTMT 0x00b31870 > UCHAR * 0x040ce9a0 [ -3] "SELECT Config, nValue FROM > MSysConf" > SDWORD -3 > Everything above this point looks ok. > > MSACCESS fff27265:fff26281 EXIT SQLExecDirect with return code > 0 (SQL_SUCCESS) > HSTMT 0x00b31870 > UCHAR * 0x040ce9a0 [ -3] "SELECT Config, nValue FROM > MSysConf" > SDWORD -3 > Here is where it gets strange. The above statement should have a return code of -1 if the table does not exist. And theerror message should say so. (I just this verified this on my system.) The next few statements tries to cope with the result set and it is not happy with what it is getting. > > MSACCESS fff27265:fff26281 ENTER SQLFetch > HSTMT 0x00b31870 > > MSACCESS fff27265:fff26281 EXIT SQLFetch with return code -1 > (SQL_ERROR) > HSTMT 0x00b31870 > > MSACCESS fff27265:fff26281 ENTER SQLError > HENV 0x00b30204 > HDBC 0x00b31668 > HSTMT 0x00b31870 > UCHAR * 0x0062c6ac (NYI) > SDWORD * 0x0062c6c8 > UCHAR * 0x0089a9cc > SWORD 8192 > SWORD * 0x0062c6de > > MSACCESS fff27265:fff26281 ENTER SQLErrorW > HENV 0x00b30204 > HDBC 0x00b31668 > HSTMT 0x00b31870 > WCHAR * 0x0062c25c (NYI) > SDWORD * 0x0062c6c8 > WCHAR * 0x0062c268 > SWORD 1024 > SWORD * 0x0062c6de > > MSACCESS fff27265:fff26281 EXIT SQLErrorW with return code 0 > (SQL_SUCCESS) > HENV 0x00b30204 > HDBC 0x00b31668 > HSTMT 0x00b31870 > WCHAR * 0x0062c25c (NYI) > SDWORD * 0x0062c6c8 (3) > WCHAR * 0x0062c268 [ 74] "Bindings were not allocated > properly." > SWORD 1024 > SWORD * 0x0062c6de (74) > ... > > I verified again using pg_dumpall, that there is no table MSysConf. > And - even better: postmasters log says in that moment: > ERROR: msysconf: Table does not exist. > So I think I can be shure of that. > > has anyone seen that before? Not I.
pgsql-interfaces by date: