headers
Nick Gorham | 2 Mar 2003 10:46
Favicon

- Re: unixODBC: Prepared statements and invalid cursors

John Anderson wrote:

>>
>>I would expect you to need a SQLCloseCursor or SQLFreeStatement( , 
>>SQL_CLOSE ) after the SQLFetchScroll returned SQL_NO_DATA.
>>
>>I havn't got the docs at home at the moment, but I will check on monday, 
>>but AFAIK the SQLFetchScroll returning SQL_NO_DATA will not return the 
>>statement to when it can be prepared, there is still a result set in 
>>existance, you could (for example) scroll backwards.
> 
> 
> Isn't this how prepared statements are supposed to work? You prepare it
> once, and then you can bind parameters to it several times?

Not thats fine, but you need to close the result set.

if you have a result set the sequence is

SQLPrepare
SQLBind
SQLExecute
SQLFetch...
SQLCloseCursor
SQLExecute
SQLFetch...
SQLCloseCursor

if you havn't got a result set creating stmt
SQLPrepare
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Langasek | 3 Mar 2003 03:28
Favicon

- "These are not supported on 64bit ODBC according to MS"

Well, I noticed that, when trying to use -DDO_YOU_KNOW_WHAT_YOUR_ARE_DOING on
64-bit platforms to get support for passing 64-bit pointer types, the
following set of definitions is used in sqltypes.h:

typedef int             SQLINTEGER;
typedef unsigned int    SQLUINTEGER;
typedef long            SQLLEN;
typedef unsigned long   SQLULEN;
typedef unsigned long   SQLSETPOSIROW;
/* 
 * These are not supprted on 64bit ODBC according to MS 
 * typedef SQLULEN SQLROWCOUNT;
 * typedef SQLULEN SQLROWSETSIZE;
 * typedef SQLULEN SQLTRANSID;
 * typedef SQLLEN SQLROWOFFSET;
 */

IIRC, the entire reason for adding the DO_YOU_KNOW_WHAT_YOUR_ARE_DOING
flag was to allow proper 64-bit support of ODBC features that were
improperly defined by MS, so this seems a bit contradictory. :)  It also
makes it impossible to compile unixODBC with reasonable ODBC 3 support on
64-bit platforms.

If Microsoft has failed to publish a spec that properly addresses integer
size issues on 64-bit platforms, as far as I'm concerned that's their
problem.  *My* problem (our problem? :) is delivering an ODBC library
that actually *works* on 64-bit platforms, rather than one that conforms
to a spec that implies pointer truncation and segfaults.  If that means
fixing bugs in the 64-bit spec that MS hasn't even identified yet, that's
fine with me; they'll have to fix the spec eventually, if they ever hope
(Continue reading)

Permalink | Reply | 602 comments |
headers
Nick Gorham | 3 Mar 2003 10:37
Favicon

Re: - "These are not supported on 64bit ODBC according to MS"

Steve Langasek wrote:
> Well, I noticed that, when trying to use -DDO_YOU_KNOW_WHAT_YOUR_ARE_DOING on
> 64-bit platforms to get support for passing 64-bit pointer types, the
> following set of definitions is used in sqltypes.h:
> 
> typedef int             SQLINTEGER;
> typedef unsigned int    SQLUINTEGER;
> typedef long            SQLLEN;
> typedef unsigned long   SQLULEN;
> typedef unsigned long   SQLSETPOSIROW;
> /* 
>  * These are not supprted on 64bit ODBC according to MS 
>  * typedef SQLULEN SQLROWCOUNT;
>  * typedef SQLULEN SQLROWSETSIZE;
>  * typedef SQLULEN SQLTRANSID;
>  * typedef SQLLEN SQLROWOFFSET;
>  */
> 
> IIRC, the entire reason for adding the DO_YOU_KNOW_WHAT_YOUR_ARE_DOING
> flag was to allow proper 64-bit support of ODBC features that were
> improperly defined by MS, so this seems a bit contradictory. :)  It also
> makes it impossible to compile unixODBC with reasonable ODBC 3 support on
> 64-bit platforms.
> 
Hi, the reason for the name, and the reason that its not the default, is 
one thing. Existing apps. If I made the default the same as it would be 
for MS, then all existing apps on 64 bit platforms would fail to work.

Its a big (IMHO) problem, and its made worse by the fact that existing 
drivers would also fail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
sjors | 3 Mar 2003 13:17
Picon

- ODBC?

Hi,

I'm sorry to bother you but since you're the experts I will. Since I
moved from Redhat7.2 to redhat 8, and with that from postgres 7.1 to
7.2.3 and unixodbc2.0 to 2.2, I noticed some strange behaviour with a
program I use (grass5). BTW with all my trying I'm now at 7.3.2 and
unixODBC2.5.
In general everything is working, postres and unixodbc, also within the
grass5 I can do select and list tables etc. The problem arises when I do
an update on a table.
The developers at grass5 don't seem to have a clue as the code involved
did not change for more than a year. That set me searching for an anwser.
So first thing I noticed when running odbctest is when I do full connect
with default I get:

Diag(hdbc 0x8240260):01000:0:[unixODBC][Driver Manager]Driver does not
support the requested version
Full Connect Succeeded

Doing the same with setting ODBC version =2, I get : Full Connect Succeeded

Another thing I get a lot with options=default (get all data) :
Diag(hstmt 0x82596b8):S1010:0:[unixODBC][Driver Manager]Function
sequence error
  SQLNumResultCols() failed

The last going oke with version=2

Also when looking in the trace log, after running the command in grass5,
I see:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nick Gorham | 3 Mar 2003 14:12
Favicon

Re: - ODBC?

sjors wrote:
> Hi,
> 
> I'm sorry to bother you but since you're the experts I will. Since I
> moved from Redhat7.2 to redhat 8, and with that from postgres 7.1 to
> 7.2.3 and unixodbc2.0 to 2.2, I noticed some strange behaviour with a
> program I use (grass5). BTW with all my trying I'm now at 7.3.2 and
> unixODBC2.5.
> In general everything is working, postres and unixodbc, also within the
> grass5 I can do select and list tables etc. The problem arises when I do
> an update on a table.
> The developers at grass5 don't seem to have a clue as the code involved
> did not change for more than a year. That set me searching for an anwser.
> So first thing I noticed when running odbctest is when I do full connect
> with default I get:
> 
> Diag(hdbc 0x8240260):01000:0:[unixODBC][Driver Manager]Driver does not
> support the requested version
> Full Connect Succeeded
> 
> Doing the same with setting ODBC version =2, I get : Full Connect Succeeded
> 
> Another thing I get a lot with options=default (get all data) :
> Diag(hstmt 0x82596b8):S1010:0:[unixODBC][Driver Manager]Function
> sequence error
>  SQLNumResultCols() failed

Thats just a warning message saying that the app asked for ODBC 3, but 
the driver could only offer ODBC 2.
(Continue reading)

Permalink | Reply | 1 comment |
headers
sjors | 3 Mar 2003 15:03
Picon

Re: - ODBC?

Nick Gorham wrote:

> sjors wrote:
>
>> Hi,
>>
>> I'm sorry to bother you but since you're the experts I will. Since I
>> moved from Redhat7.2 to redhat 8, and with that from postgres 7.1 to
>> 7.2.3 and unixodbc2.0 to 2.2, I noticed some strange behaviour with a
>> program I use (grass5). BTW with all my trying I'm now at 7.3.2 and
>> unixODBC2.5.
>> In general everything is working, postres and unixodbc, also within the
>> grass5 I can do select and list tables etc. The problem arises when I do
>> an update on a table.
>> The developers at grass5 don't seem to have a clue as the code involved
>> did not change for more than a year. That set me searching for an 
>> anwser.
>> So first thing I noticed when running odbctest is when I do full connect
>> with default I get:
>>
>> Diag(hdbc 0x8240260):01000:0:[unixODBC][Driver Manager]Driver does not
>> support the requested version
>> Full Connect Succeeded
>>
>> Doing the same with setting ODBC version =2, I get : Full Connect 
>> Succeeded
>>
>> Another thing I get a lot with options=default (get all data) :
>> Diag(hstmt 0x82596b8):S1010:0:[unixODBC][Driver Manager]Function
>> sequence error
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Allan Kiesling | 3 Mar 2003 18:03
Picon
Favicon

- DataManager Error "Can't initiate unicode coversion"


Apologies if this is a FAQ.  The error message above occurs after 
entering user name and (occasionally) password using the DataManager 
dialog box.  When connecting with isql the error is simply, 
"Can't SQLConnet"...  

This is a relatively recent occurence since shifting version numbers to
attain some backward compatibility, and importing tables from a slightly 
different (3.23.51) MySQL version.  Yet this problem persists after a 
complete re-install of MySQL and the ODBC libraries.  The versions are: 
unixODBC 2.2.4, MySQL 3.23.49, and MyODBC 3.51.02.  

Queries using the MySQL monitor seem to work fine.

Thanks,

Robert Kiesling

--

-- 
UnixODBC.pm - http://unixodbc-pm.org
Permalink | Reply | 1 comment |
headers
Nick Gorham | 3 Mar 2003 22:41
Favicon

Re: - DataManager Error "Can't initiate unicode coversion"

Robert Allan Kiesling wrote:
> Apologies if this is a FAQ.  The error message above occurs after 
> entering user name and (occasionally) password using the DataManager 
> dialog box.  When connecting with isql the error is simply, 
> "Can't SQLConnet"...  
> 
> This is a relatively recent occurence since shifting version numbers to
> attain some backward compatibility, and importing tables from a slightly 
> different (3.23.51) MySQL version.  Yet this problem persists after a 
> complete re-install of MySQL and the ODBC libraries.  The versions are: 
> unixODBC 2.2.4, MySQL 3.23.49, and MyODBC 3.51.02.  
> 
> Queries using the MySQL monitor seem to work fine.

Hi, that warning is because the build detected iconv to do unicode 
conversions, but at run time iconv failed to initialise the requierd 
char sets.

Simple solution, get the 2.2.5 build on the web site now, this can be 
configures with a --enable-iconv=no option. This will remove the warning.

--
NIck
Permalink | Reply | 0 comments |
headers
Nick Gorham | 4 Mar 2003 15:10
Favicon

Re: - re:[unixODBC-DEV]-ODBC?

sjors wrote:
> Hi,
> 
> With the help of one the developers I did some debugging. The module in 
> grass5 causing the trouble is writing characters instead of integers. 
> Could this be the result of not using the right ODBC version? If so, how 
> in the code do we explicitely declare the ODBC version, if neede at all? 
> Or is there another solution?
> 
> Greetings Sjors
> 
Well the way to avoid the version problem, is either to use

SQLAllocEnv

to get the environment, that tells the driver manager that its a ODBC 2 
app, or after calling

SQLAllocHandle( SQL_ENV ):

calls

SQLSetEnvAttr( henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER) SQL_OV_ODBC2, 0 );

This will also tell the driver manager to use ODBC 2.

However I don't know if this will affect the later problem.

--

-- 
Nick Gorham
(Continue reading)

Permalink | Reply | 0 comments |
headers
sjors | 4 Mar 2003 15:03
Picon

- re:[unixODBC-DEV]-ODBC?

Hi,

With the help of one the developers I did some debugging. The module in 
grass5 causing the trouble is writing characters instead of integers. 
Could this be the result of not using the right ODBC version? If so, how 
in the code do we explicitely declare the ODBC version, if neede at all? 
Or is there another solution?

Greetings Sjors
Permalink | Reply | 1 comment |

Gmane