Discussion:
[Firebird-odbc-devel] incorrect octet buffer length
bill lam
2010-10-01 14:28:27 UTC
Permalink
Using the latest v.2 odbcfb driver against the same fb 2.5 server, I found
the octet buffer length as reported by SqlDescribeCol for SQL_INTEGER is incorrect for the
linux 64-bit odbcfb. It should be 4 (window version is correct) but it
reported 8. When retrieving data using column binding, it actual fill 8 bytes
or each SQL_INTEGER, with garbage in the upper 4 bytes.

I also found the it failed to update correctly using sqlbindparameter for
SQL_INTEGER, it did report any error but all field following the integer
field were in fact not updated. It might related to this bug.

No problem for the other 3 combinations: W64 W32 L32.

window 64-bit driver
+-----------+---------+-----------------+-----------+-------------+
|COLUMN_NAME|DATA_TYPE|TYPE_NAME |COLUMN_SIZE|BUFFER_LENGTH|
+-----------+---------+-----------------+-----------+-------------+
|CODEN |4 |INTEGER |10 |4 |
+-----------+---------+-----------------+-----------+-------------+
|DESCR1 |_9 |VARCHAR |10 |30 |
+-----------+---------+-----------------+-----------+-------------+
|DESCR2 |_9 |VARCHAR |10 |30 |
+-----------+---------+-----------------+-----------+-------------+
|TYPEN |4 |INTEGER |10 |4 |
+-----------+---------+-----------------+-----------+-------------+
|MAXN |4 |INTEGER |10 |4 |
+-----------+---------+-----------------+-----------+-------------+
|MEMO1 |_4 |BLOB SUB_TYPE BLR|2147483647 |2147483647 |
+-----------+---------+-----------------+-----------+-------------+

linux 64-bit driver
+-----------+---------+-----------------+-----------+-------------+
|COLUMN_NAME|DATA_TYPE|TYPE_NAME |COLUMN_SIZE|BUFFER_LENGTH|
+-----------+---------+-----------------+-----------+-------------+
|CODEN |4 |INTEGER |10 |8 |
+-----------+---------+-----------------+-----------+-------------+
|DESCR1 |_9 |VARCHAR |10 |30 |
+-----------+---------+-----------------+-----------+-------------+
|DESCR2 |_9 |VARCHAR |10 |30 |
+-----------+---------+-----------------+-----------+-------------+
|TYPEN |4 |INTEGER |10 |8 |
+-----------+---------+-----------------+-----------+-------------+
|MAXN |4 |INTEGER |10 |8 |
+-----------+---------+-----------------+-----------+-------------+
|MEMO1 |_4 |BLOB SUB_TYPE BLR|2147483647 |2147483647 |
+-----------+---------+-----------------+-----------+-------------+
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
bill lam
2010-10-05 09:28:30 UTC
Permalink
Hi, is this driver still maintained? I also found other bugs but want a
confirmation from maintainers before further reporting.

Thanks.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Alexander Potapchenko
2010-10-05 10:14:38 UTC
Permalink
Post by bill lam
Hi, is this driver still maintained? I also found other bugs but want a
confirmation from maintainers before further reporting.
Thanks.
Hi, this question is discussed now.
Most likely that I will develop the driver to final release 2.0 and then
I will work on version 2.1..


Best regards,
Alexander
--
Alexander Potapchenko
Senior developer
bill lam
2010-10-05 10:31:34 UTC
Permalink
Post by Alexander Potapchenko
Post by bill lam
Hi, is this driver still maintained? I also found other bugs but want a
confirmation from maintainers before further reporting.
Thanks.
Hi, this question is discussed now.
Most likely that I will develop the driver to final release 2.0 and then
I will work on version 2.1..
Hi Alexander,
I'm glad to hear this, thank you for your effect.

I browsed the source and found it use long instead of int in various
places, and assign sizeof(long) to buffer length for SQLINTEGER.
Hopefully this and other 64-bit and unicode issues can be cleaned up.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Steve Cookson
2010-10-05 14:27:58 UTC
Permalink
I guess this the source of the problem I had earlier this year.
I am using Perl on Linux (Kubuntu 9.10) with Firebird 2.1. I
wanted to use
ODBC, but in the end I gave up using it because I couldn't
get the DATE or
number formats to work. Instead I used the DBI::Interbase
driver, while it
works, it is subject to occasional crashes, so I'd like to go
back to trying
ODBC.
I'd still like to use ODBC, but for the moment, I'm putting up with DBI. Do
we have any idea when the next release will be available? If I can help
with testing, I'd be happy to.

Regards

Steve
bill lam
2010-10-05 14:33:37 UTC
Permalink
Post by Steve Cookson
I guess this the source of the problem I had earlier this year.
I am using Perl on Linux (Kubuntu 9.10) with Firebird 2.1. I
wanted to use
ODBC, but in the end I gave up using it because I couldn't
get the DATE or
number formats to work. Instead I used the DBI::Interbase
driver, while it
works, it is subject to occasional crashes, so I'd like to go
back to trying
ODBC.
I'd still like to use ODBC, but for the moment, I'm putting up with DBI. Do
we have any idea when the next release will be available? If I can help
with testing, I'd be happy to.
The 32-bit driver works ok for all common data types that I used. Except
sql_numeric which I don't need so not tested. But the 64-bit drivers need
some fixes. Perhaps you could give some context of your problem, did you
call odbc api directly or via some wrapping library?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Loading...