headers
Wouter van Atteveldt | 3 Jun 02:49

mx.odbc segmentation fault on fetching string

Dear list,

I am evaluating mx.odbc for connecting to a MS SQL server from my Linux machine using freetds 0.82. I can
connect and query using isql without problem, but I get a segmentation fault if I fetch using the mx.odbc interface.

wva <at> amcat:~/tmp$ isql -v AmcatDB <UID> <PWD>
+---------------------------------------+
| Connected!
[...]
+---------------------------------------+
SQL> select top 1 projectid, name from projects
[...]
| 1          | test
[...]
SQLRowCount returns 1
1 rows fetched

wva <at> amcat:~/tmp$ python testodbc.py
connected to Microsoft SQL Server 08.00.2039
Executed, fetching...
[(1,)]
Executed, fetching...
Segmentation fault

wva <at> amcat:~/tmp$ cat testodbc.py
import mx.ODBC
db = mx.ODBC.unixODBC.connect("AmcatDB", "<UID>", "<PWD>")
print "connected to %s %s" % (db.dbms_name, db.dbms_version)
c = db.cursor()
c.executedirect("select top 1 projectid from projects")
(Continue reading)

Permalink | Reply |
headers
M.-A. Lemburg | 3 Jun 11:20
Favicon

Re: mx.odbc segmentation fault on fetching string

On 2008-06-03 02:49, Wouter van Atteveldt wrote:
> Dear list,
> 
> I am evaluating mx.odbc for connecting to a MS SQL server from my Linux machine using freetds 0.82. I can
connect and query using isql without problem, but I get a segmentation fault if I fetch using the mx.odbc interface.

isql uses a different, all-strings based access method to the ODBC
driver, so it can really only be used to verify that a connection
works, not much more.

mxODBC always tries to use the best possible access method to
avoid frequent copying and conversion of the data.

> wva <at> amcat:~/tmp$ isql -v AmcatDB <UID> <PWD>
> +---------------------------------------+
> | Connected!
> [...]
> +---------------------------------------+
> SQL> select top 1 projectid, name from projects
> [...]
> | 1          | test
> [...]
> SQLRowCount returns 1
> 1 rows fetched
> 
> wva <at> amcat:~/tmp$ python testodbc.py
> connected to Microsoft SQL Server 08.00.2039
> Executed, fetching...
> [(1,)]
> Executed, fetching...
(Continue reading)

Permalink | Reply |
headers
M.-A. Lemburg | 3 Jun 11:35
Favicon

Re: mx.odbc segmentation fault on fetching string

On 2008-06-03 11:20, M.-A. Lemburg wrote:
> On 2008-06-03 02:49, Wouter van Atteveldt wrote:
>> Dear list,
>>
>> I am evaluating mx.odbc for connecting to a MS SQL server from my 
>> Linux machine using freetds 0.82. I can connect and query using isql 
>> without problem, but I get a segmentation fault if I fetch using the 
>> mx.odbc interface.
> 
> isql uses a different, all-strings based access method to the ODBC
> driver, so it can really only be used to verify that a connection
> works, not much more.
> 
> mxODBC always tries to use the best possible access method to
> avoid frequent copying and conversion of the data.
> 
>> wva <at> amcat:~/tmp$ isql -v AmcatDB <UID> <PWD>
>> +---------------------------------------+
>> | Connected!
>> [...]
>> +---------------------------------------+
>> SQL> select top 1 projectid, name from projects
>> [...]
>> | 1          | test
>> [...]
>> SQLRowCount returns 1
>> 1 rows fetched
>>
>> wva <at> amcat:~/tmp$ python testodbc.py
>> connected to Microsoft SQL Server 08.00.2039
(Continue reading)

Permalink | Reply |
headers
M.-A. Lemburg | 3 Jun 11:56
Favicon

Re: mx.odbc segmentation fault on fetching string

We ran our test suite using our release candidate 2 of mxODBC 3.0.2
against FreeTDS 0.82 with unixODBC and iODBC, with SQL Server 2000 and
SQL Server 2005, but could not reproduce the problem you are seeing.

We've uploaded the RC2 to our server. Could you try with that
version ?

http://downloads.egenix.com/python/egenix-mxodbc-3.0.2_rc2.linux-x86_64-py2.5_ucs4.prebuilt.zip

Thanks,

On 2008-06-03 11:35, M.-A. Lemburg wrote:
> On 2008-06-03 11:20, M.-A. Lemburg wrote:
>> On 2008-06-03 02:49, Wouter van Atteveldt wrote:
>>> Dear list,
>>>
>>> I am evaluating mx.odbc for connecting to a MS SQL server from my 
>>> Linux machine using freetds 0.82. I can connect and query using isql 
>>> without problem, but I get a segmentation fault if I fetch using the 
>>> mx.odbc interface.
>>
>> isql uses a different, all-strings based access method to the ODBC
>> driver, so it can really only be used to verify that a connection
>> works, not much more.
>>
>> mxODBC always tries to use the best possible access method to
>> avoid frequent copying and conversion of the data.
>>
>>> wva <at> amcat:~/tmp$ isql -v AmcatDB <UID> <PWD>
>>> +---------------------------------------+
(Continue reading)

Permalink | Reply |
headers
M.-A. Lemburg | 3 Jun 17:43
Favicon

Re: mx.odbc segmentation fault on fetching string

For the other list members and the archives ...

After some private discussion, it turned out that using iODBC instead
of unixODBC solved the problem.

However, we were not able to reproduce the problem on our machines, so
in case you run into similar problems, please let us know.

FWIW, the only difference between our setup and Wouter's was the version
of unixODBC being used - they had 2.2.11 installed, we compile mxODBC against
the more recent 2.2.12.

Note that when using FreeTDS, it is often better to try using iODBC
as well. Our internal tests often show a much better performance of the
FreeTDS driver with iODBC than unixODBC, with much better being up to
2-3x faster depending on the usage pattern, so it's well worth a try.

Thanks.

On 2008-06-03 11:56, M.-A. Lemburg wrote:
> We ran our test suite using our release candidate 2 of mxODBC 3.0.2
> against FreeTDS 0.82 with unixODBC and iODBC, with SQL Server 2000 and
> SQL Server 2005, but could not reproduce the problem you are seeing.
> 
> We've uploaded the RC2 to our server. Could you try with that
> version ?
> 
>
http://downloads.egenix.com/python/egenix-mxodbc-3.0.2_rc2.linux-x86_64-py2.5_ucs4.prebuilt.zip 
>
(Continue reading)

Permalink | Reply |
headers
M.-A. Lemburg | 3 Jun 18:20
Favicon

Re: mx.odbc segmentation fault on fetching string

On 2008-06-03 17:43, M.-A. Lemburg wrote:
> For the other list members and the archives ...
> 
> After some private discussion, it turned out that using iODBC instead
> of unixODBC solved the problem.
> 
> However, we were not able to reproduce the problem on our machines, so
> in case you run into similar problems, please let us know.
> 
> FWIW, the only difference between our setup and Wouter's was the version
> of unixODBC being used - they had 2.2.11 installed, we compile mxODBC 
> against the more recent 2.2.12.

FWIW: We tried 2.2.11 as well and could still not reproduce the
problem.

Perhaps Debian builds unixODBC using the "REAL 64bit" option that
unixODBC provides.

This would lead to a segfault when used with the mx.ODBC.unixODBC
package we provide, since in "REAL 64bit" mode, unixODBC doesn't
follow the MS ODBC standard. It uses the native 64-bit support
and bit lengths on Linux instead.

> Note that when using FreeTDS, it is often better to try using iODBC
> as well. Our internal tests often show a much better performance of the
> FreeTDS driver with iODBC than unixODBC, with much better being up to
> 2-3x faster depending on the usage pattern, so it's well worth a try.
> 
> Thanks.
(Continue reading)

Permalink | Reply |

Gmane