Thread: VARCHAR, CHAR types changed ?
Hi,
I am trying the new, or most actual database under Windows 2000 (8.0).
This driver don't let
my test application crash. Compared to the old driver and Database
(07.03.0200), my
other application should run too.
But I get some unexplainable changes in supported types. My
VARCHAR(100) and even,
if I change it to CHAR(100), isn't any more supported.
(The error message from me reports -8 as DataType)
What has been changed ?
Thanks, Lothar
My detection code for data types looks like this:
switch (DataType) {
case SQL_CHAR:
case SQL_VARCHAR:
case SQL_LONGVARCHAR:
buffer = malloc((ColumnSize+1)*rows);
_DataType = DataType;
bound = 1; // Try a spacer
for bugfix
memset(buffer, 0, (ColumnSize+1)*rows+20);
ret = SQLBindCol(hstmt, column, SQL_C_DEFAULT, buffer,
(ColumnSize+1),
&cbBufferLength);
if (ret != SQL_SUCCESS) query->dbError("SQLBindCol()",
hstmt);
break;
default:
cout << "lbBoundColumn::bindColumn(...) failed: " <<
"Unknown or not supported datatype for column '" <<
columnName << "': " << DataType << endl;
break;
}
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of > lothar.behrens@lollisoft.de > Sent: 25 November 2005 12:09 > To: pgsql-odbc@postgresql.org > Subject: [ODBC] VARCHAR, CHAR types changed ? > > Hi, > > I am trying the new, or most actual database under Windows 2000 (8.0). > This driver don't let > my test application crash. Compared to the old driver and Database > (07.03.0200), my > other application should run too. > > But I get some unexplainable changes in supported types. My > VARCHAR(100) and even, > if I change it to CHAR(100), isn't any more supported. > > (The error message from me reports -8 as DataType) > > What has been changed ? Looks like you are using the unicode version of the driver (-8 is SQL_C_WCHAR). You could either: - Change to the ANSI driver, which should never return SQL_C_WCHAR. - Update your code to handle Unicode data. - Update your code to recognise SQL_C_WCHAR, but then request SQL_C_CHAR data instead. I would plump for the first option, unless you want to support Unicode. Regards, Dave.
I have tried to use ANSI driver. It crashes :-(
My code to connect and setup a statement looks like this:
SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (void*) SQL_OV_ODBC3, 0);
SQLSetConnectAttr(hdbc,
SQL_ATTR_ODBC_CURSORS,
SQL_CUR_USE_IF_NEEDED, 0);
SQLConnect(hdbc, (unsigned char*) DSN, SQL_NTS,
(unsigned char*) user, SQL_NTS,
(unsigned char*) passwd, SQL_NTS);
SQLSetConnectOption(hdbc, SQL_AUTOCOMMIT, SQL_AUTOCOMMIT_ON);
SQLSetStmtOption(hstmt, SQL_ATTR_CONCURRENCY, SQL_CONCUR_ROWVER);
SQLSetStmtOption(hstmt, SQL_CURSOR_TYPE, SQL_CURSOR_KEYSET_DRIVEN);
This is my standard setup to do database work. All these steps do not
report any error.
The following happens:
char buf[] = "create table regressiontest ("
"test char(100) DEFAULT 'Nothing',\n"
"btest bool DEFAULT false, "
"btest1 bool DEFAULT false"
");";
// Do not internally collect meta data, like foreign key to primary key
mapping
query->skipFKCollecting();
query->query(buf);
// Tese statements work properly
query1->query("insert into regressiontest (test) values('Nix')");
query1->query("insert into regressiontest (btest) values(true)");
query1->query("insert into regressiontest (btest1) values(true)");
// This statement crashes inside SQLExecDirect(...)
query1->query("select test, btest, btest1 from regressiontest");
query1->PrintData();
query->query("drop table regressiontest");
The code is simple console based, but my database classes encapsulate
all ODBC
CLI calls. The internal statement handle is reused. The table get's
created and filled.
Any ideas ?
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of
> lothar.behrens@lollisoft.de
> Sent: 25 November 2005 13:21
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] VARCHAR, CHAR types changed ?
>
> I have tried to use ANSI driver. It crashes :-(
>
> My code to connect and setup a statement looks like this:
>
<snip code>
>
> The code is simple console based, but my database classes encapsulate
> all ODBC
> CLI calls. The internal statement handle is reused. The table get's
> created and filled.
>
> Any ideas ?
Well, I've tried the code below which is roughly as close as I can get
to what you posted (not having your query class), and it SQLExecDirect's
just fine here. Any thoughts on what might be significantly different
here?:
Regards, Dave.
#include <windows.h>
#include <sqlext.h>
#include <stdio.h>
int main(void)
{
HENV henv = NULL; // Env
Handle from SQLAllocEnv()
HDBC hdbc = NULL; //
Connection handle
HSTMT hstmt = NULL; //
Statement handle
UCHAR DSN[SQL_MAX_DSN_LENGTH] = "ansi"; // Data
Source Name buffer
UCHAR user[64] = "postgres"; // User
ID buffer
UCHAR* passwd = NULL; //
Password buffer
SQLAllocEnv (&henv);
SQLAllocConnect (henv, &hdbc);
SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (void*) SQL_OV_ODBC3, 0);
SQLSetConnectAttr(hdbc,
SQL_ATTR_ODBC_CURSORS,
SQL_CUR_USE_IF_NEEDED, 0);
SQLConnect(hdbc, DSN, SQL_NTS,
user, SQL_NTS,
passwd, SQL_NTS);
SQLSetConnectOption(hdbc, SQL_AUTOCOMMIT, SQL_AUTOCOMMIT_ON);
SQLAllocStmt (hdbc, &hstmt);
SQLSetStmtOption(hstmt, SQL_ATTR_CONCURRENCY, SQL_CONCUR_ROWVER);
SQLSetStmtOption(hstmt, SQL_CURSOR_TYPE, SQL_CURSOR_KEYSET_DRIVEN);
UCHAR buf1[] = "create table regressiontest ("
"test char(100) DEFAULT 'Nothing',\n"
"btest bool DEFAULT false, "
"btest1 bool DEFAULT false"
");";
UCHAR buf2[] = "insert into regressiontest (test) values('Nix')";
UCHAR buf3[] = "insert into regressiontest (btest) values(true)";
UCHAR buf4[] = "insert into regressiontest (btest1) values(true)";
SQLExecDirect(hstmt, buf1, sizeof(buf1));
SQLExecDirect(hstmt, buf2, sizeof(buf2));
SQLExecDirect(hstmt, buf3, sizeof(buf3));
SQLExecDirect(hstmt, buf4, sizeof(buf4));
// This statement crashes inside SQLExecDirect(...)
UCHAR buf5[] = "select test, btest, btest1 from regressiontest";
SQLExecDirect(hstmt, buf5, sizeof(buf5));
// UCHAR buf6[] = "drop table regressiontest";
// SQLExecDirect(hstmt, buf6, sizeof(buf6));
// Free the allocated statement handle
SQLFreeStmt (hstmt, SQL_DROP);
// Free the allocated connection handle
SQLFreeConnect (hdbc);
// Free the allocated ODBC environment handle
SQLFreeEnv (henv);
return 0;
}
Am 25 Nov 2005 um 14:35 hat Dave Page geschrieben:
My query function first calls SQLExecDirect(hstmt, _query, SQL_NTS);
I have changed this to do exactly the same as your sample and pass the length of the
string. No way.
As you have put together a complete sample application, I have tried this compiled
with Open Watcom 1.3 and MS Visual C++ 6.0. Both do the same. They crash inside
the call to SQLExecDirect.
My registered ODBC driver DLL is 335.872 bytes and from 11.11.2005 08:29:42
With Open Watcom debugger, I found the crash inside ConfigDSN. Is there any
change in the ordinals inside the PSQLODBCA.dll ?
The same happens, if I rename the DLL filenames :-)
Regards
Lothar
>
>
> > -----Original Message-----
> > From: pgsql-odbc-owner@postgresql.org
> > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of
> > lothar.behrens@lollisoft.de
> > Sent: 25 November 2005 13:21
> > To: pgsql-odbc@postgresql.org
> > Subject: Re: [ODBC] VARCHAR, CHAR types changed ?
> >
> > I have tried to use ANSI driver. It crashes :-(
> >
> > My code to connect and setup a statement looks like this:
> >
> <snip code>
>
> >
> > The code is simple console based, but my database classes encapsulate
> > all ODBC
> > CLI calls. The internal statement handle is reused. The table get's
> > created and filled.
> >
> > Any ideas ?
>
> Well, I've tried the code below which is roughly as close as I can get
> to what you posted (not having your query class), and it SQLExecDirect's
> just fine here. Any thoughts on what might be significantly different
> here?:
>
> Regards, Dave.
>
> #include <windows.h>
> #include <sqlext.h>
> #include <stdio.h>
>
>
> int main(void)
> {
> HENV henv = NULL; // Env
> Handle from SQLAllocEnv()
> HDBC hdbc = NULL; //
> Connection handle
> HSTMT hstmt = NULL; //
> Statement handle
> UCHAR DSN[SQL_MAX_DSN_LENGTH] = "ansi"; // Data
> Source Name buffer
> UCHAR user[64] = "postgres"; // User
> ID buffer
> UCHAR* passwd = NULL; //
> Password buffer
>
> SQLAllocEnv (&henv);
>
> SQLAllocConnect (henv, &hdbc);
>
> SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (void*) SQL_OV_ODBC3, 0);
>
> SQLSetConnectAttr(hdbc,
> SQL_ATTR_ODBC_CURSORS,
> SQL_CUR_USE_IF_NEEDED, 0);
>
> SQLConnect(hdbc, DSN, SQL_NTS,
> user, SQL_NTS,
> passwd, SQL_NTS);
>
> SQLSetConnectOption(hdbc, SQL_AUTOCOMMIT, SQL_AUTOCOMMIT_ON);
>
> SQLAllocStmt (hdbc, &hstmt);
>
> SQLSetStmtOption(hstmt, SQL_ATTR_CONCURRENCY, SQL_CONCUR_ROWVER);
> SQLSetStmtOption(hstmt, SQL_CURSOR_TYPE, SQL_CURSOR_KEYSET_DRIVEN);
>
>
>
> UCHAR buf1[] = "create table regressiontest ("
> "test char(100) DEFAULT 'Nothing',\n"
> "btest bool DEFAULT false, "
> "btest1 bool DEFAULT false"
> ");";
> UCHAR buf2[] = "insert into regressiontest (test) values('Nix')";
> UCHAR buf3[] = "insert into regressiontest (btest) values(true)";
> UCHAR buf4[] = "insert into regressiontest (btest1) values(true)";
>
>
> SQLExecDirect(hstmt, buf1, sizeof(buf1));
> SQLExecDirect(hstmt, buf2, sizeof(buf2));
> SQLExecDirect(hstmt, buf3, sizeof(buf3));
> SQLExecDirect(hstmt, buf4, sizeof(buf4));
>
> // This statement crashes inside SQLExecDirect(...)
> UCHAR buf5[] = "select test, btest, btest1 from regressiontest";
> SQLExecDirect(hstmt, buf5, sizeof(buf5));
>
> // UCHAR buf6[] = "drop table regressiontest";
> // SQLExecDirect(hstmt, buf6, sizeof(buf6));
>
> // Free the allocated statement handle
> SQLFreeStmt (hstmt, SQL_DROP);
>
> // Free the allocated connection handle
> SQLFreeConnect (hdbc);
>
> // Free the allocated ODBC environment handle
> SQLFreeEnv (henv);
>
> return 0;
> }
>
>
--
Lothar Behrens | Rapid Prototyping ...
Rosmarinstr 3 |
40235 Düsseldorf | www.lollisoft.de
Am 25 Nov 2005 um 20:27 hat lothar.behrens@lollisoft.de geschrieben:
Hi,
I probably have found the bug. It has to do with keysed driven cursors activated.
After changing the lines in connection.c near 1500, I have got rid of the bug in the
test program. Here is the code:
if (create_keyset)
// res->next is a NULL pointer and as the macro set a TRUE value into
// this structure or what ever it is, this cause the bug.
//
// Must res->next be not NULL or is my variant correct ?
//QR_set_haskeyset(res->next);
QR_set_haskeyset(res);
I still have another problem in my code after this change, but if this is not the bug,
please let me know.
Regards, Lothar
--
Lothar Behrens | Rapid Prototyping ...
Rosmarinstr 3 |
40235 Düsseldorf | www.lollisoft.de
On 25/11/05 11:22 pm, "lothar.behrens@lollisoft.de" <lothar.behrens@lollisoft.de> wrote: > Am 25 Nov 2005 um 20:27 hat lothar.behrens@lollisoft.de geschrieben: > > Hi, > > I probably have found the bug. It has to do with keysed driven cursors > activated. > After changing the lines in connection.c near 1500, I have got rid of the bug > in the > test program. Here is the code: > > if (create_keyset) > // res->next is a NULL pointer and as the macro set a TRUE value into > // this structure or what ever it is, this cause the bug. > // > // Must res->next be not NULL or is my variant correct ? > //QR_set_haskeyset(res->next); > QR_set_haskeyset(res); > > I still have another problem in my code after this change, but if this is not > the bug, > please let me know. Oh, I don't suppose you have the updateable cursors option turned on do you? That's experimental, and known to be buggy with keyset cursors: http://pgfoundry.org/tracker/index.php?func=detail&aid=1000413&group_id=1000 125&atid=538 Regards, Dave