Status of GNADE ODBC under Debian 64-bit

Status of GNADE ODBC under Debian 64-bit

[Dmitry A. Kazakov]

What is the status of the bug reported by Ludovic Brenta:

https://sourceforge.net/tracker/?func=detail&aid=1591916&group_id=23045&atid=377331

I am asking because it seems there that the latest version of libgnadeodbc2
has the issue not resolved. In particular gnu-db-sqcli.adb has GetData
declared as:

      function GetData (StatementHandle : in SQLHSTMT;
                        ColumnNumber    : in SQL_Column_Number;
                        TargetType      : in SQL_C_DATA_TYPE;
                        TargetValue     : in SQLPOINTER;
                        BufferLength    : in SQLINTEGER;
                        StrLen_Or_Ind   : access SQLINTEGER)
                        return SQLRETURN;

This is wrong and causes programs using GNADE ODBC crash.

BufferLength must have been SQLLEN. StrLen_Or_Ind must have been access
SQLLEN. The type SQLLEN is 64-bit under Debian 64-bit (32-bit under Debian
32-bit).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Status of GNADE ODBC under Debian 64-bit

[Graham Stark]

I'm interested in this as I use GNADE quite a bit. 

If you just change SQLUINTEGER to SQLUBIGINT in the indicated places Ludovic's
warning goes away. It seems harmless either way, to the limited extent that I understand the code - the thing that's declared as a pointer is really just a bitmap, so it's just that the top 32 bits can't be set by that function.

The SQLLEN thing looks like a different problem and really quite nasty - I hadn't come across this before. My reading of it is that some ODBC drivers might need 32 bits there even on 64 bit systems; see this, for instance: http://www.martin-evans.me.uk/node/99

I have notice some funny behaviour retrieving strings from databases, where the length is not returned correctly, so maybe that's the cause. Never seen a crash, though.

Graham

Re: Status of GNADE ODBC under Debian 64-bit

[Dmitry A. Kazakov]

On Tue, 4 Sep 2012 02:40:32 -0700 (PDT), Graham Stark wrote:

> I'm interested in this as I use GNADE quite a bit. 
> 
> If you just change SQLUINTEGER to SQLUBIGINT in the indicated places Ludovic's
> warning goes away.

Maybe, but he reported rather a need to verify consistency on 64-bit
platform.

Should I report it independently to sourceforge?

> The SQLLEN thing looks like a different problem and really quite nasty - I
> hadn't come across this before. My reading of it is that some ODBC drivers
> might need 32 bits there even on 64 bit systems; see this, for instance:
> http://www.martin-evans.me.uk/node/99
> 
> I have notice some funny behaviour retrieving strings from databases,
> where the length is not returned correctly, so maybe that's the cause.
> Never seen a crash, though.

Specifically to unixodbc and Debian, the macro BUILD_LEGACY_64_BIT_MODE if
defined in sqltypes.h, makes SQLLEN 32-bit. When undefined it is 64-bit.
The effect of SQLINTEGER (always 32-bit) passed instead of 64-bit is memory
corruption.

It should also become an issue for native Windows 64-bit applications, once
GNAT to support them.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Status of GNADE ODBC under Debian 64-bit

[Stephen Leake]

As far as I know, there is no current Debian maintainer for GNADE. I was
the maintainer, but I've resigned, partly because the code is hard to
maintain in the first place, and needs to be re-written.

I suggest you switch to gnatcoll, which includes Ada front-ends for
postgres and SQLite3 (but not ODBC). That code is better written, and
actively maintained, supported by paying customers. 

It also includes higher-level object oriented front-ends.

If paying customers lobby for ODBC support, it will happen.

-- 
-- Stephe

Re: Status of GNADE ODBC under Debian 64-bit

[Ludovic Brenta]

Stephen Leake wrote on comp.lang.ada:
> As far as I know, there is no current Debian maintainer for GNADE.
> I was the maintainer, but I've resigned, partly because the code is
> hard to maintain in the first place, and needs to be re-written.
> 
> I suggest you switch to gnatcoll, which includes Ada front-ends for
> postgres and SQLite3 (but not ODBC). That code is better written,
> and actively maintained, supported by paying customers. 
> 
> It also includes higher-level object oriented front-ends.
> 
> If paying customers lobby for ODBC support, it will happen.

But gnatcoll doesn't have a Debian maintainer either and is not even
packaged in Debian.  If someone here on comp.lang.ada would like to
make a difference, the one thing to know is that the sources of
gnatcoll are part of the sources of GPS, therefore packaging gnatcoll
for Debian requires modifying the packaging of gnat-gps; see
http://bugs.debian.org/640532.  As much as I would like to do that
work myself, I lack time for it.

PS. AFAIU, part of gnatcoll is built on top of GNADE (and includes a
fork of GNADE).

-- 
Ludovic Brenta.

Re: Status of GNADE ODBC under Debian 64-bit

[Graham Stark]

I'd think Gnade is worth persevering with. 

The changes that need to be made to support 64 bit ODBC are detailed here:

http://support.microsoft.com/kb/298678

the scary bit is that (if I've read this right) sometimes function returns are 32 bit and sometimes 64 bit depending on the inputs. We're going to need a slightly thicker binding than at present to handle this, I'd think.


Graham

Re: Status of GNADE ODBC under Debian 64-bit

[Dmitry A. Kazakov]

On Fri, 7 Sep 2012 04:25:32 -0700 (PDT), Graham Stark wrote:

> the scary bit is that (if I've read this right) sometimes function returns
> are 32 bit and sometimes 64 bit depending on the inputs.

This was always the case for most C bindings and MS ones especially.

> We're going to
> need a slightly thicker binding than at present to handle this, I'd think.

Yes. Simple components provide a safer layer on top GNADE ODBC. E.g.
controlled types for handles, typed SQLGetData, etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Status of GNADE ODBC under Debian 64-bit

[Stephen Leake]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> PS. AFAIU, part of gnatcoll is built on top of GNADE (and includes a
> fork of GNADE).

The GPL 2012 version says (in gnatcoll-gpl-2012-src/docs/sql.rs):

    The *gnade* part in the file names
  indicate that this code was initially inspired by the **GNADE** library
  that used to be available on the internet. Part of the code might in fact
  come from that library.

-- 
-- Stephe

Re: Status of GNADE ODBC under Debian 64-bit

[Graham Stark]

It would be interesting to know if the other database interfaces out there (I know of gnatcol and SOCI)  are immune to these 64/32 bit problems.

Re: Status of GNADE ODBC under Debian 64-bit

[Dmitry A. Kazakov]

On Fri, 07 Sep 2012 05:51:09 -0400, Stephen Leake wrote:

> As far as I know, there is no current Debian maintainer for GNADE. I was
> the maintainer, but I've resigned, partly because the code is hard to
> maintain in the first place, and needs to be re-written.

Thank you for the information.

> I suggest you switch to gnatcoll, which includes Ada front-ends for
> postgres and SQLite3 (but not ODBC). That code is better written, and
> actively maintained, supported by paying customers. 

Being DB-specific none of these is an alternative to ODBC.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Status of GNADE ODBC under Debian 64-bit

[Georg Bauhaus]

On 07.09.12 11:51, Stephen Leake wrote:
> I suggest you switch to gnatcoll, which includes Ada front-ends for
> postgres and SQLite3 (but not ODBC). That code is better written, and
> actively maintained, supported by paying customers. 

GNATcoll relies a few GNAT specific packages; any experience whether
these work with other Ada compilers?

with GNAT.Strings, GNATCOLL.*, GNAT.Calendar... etc. Nothing
terrible, and I am not complaining, just mentioning.

Also, for those who might need copy protection for their
sources, the license (GPL) might not be what they'd like, IINM.