Re: Problems with the way unixODBC switched to 64-bit SQLLEN

Nick Gorham <[email protected]>
Newsgroups gmane.comp.db.unixodbc.devel
Message-ID <[email protected]>
M.-A. Lemburg wrote:
> Nick Gorham wrote:
>   
>> M.-A. Lemburg wrote:
>>     
>>> I'd suggest to quickly move to unixODBC 2.3.0 to signal
>>> the change in API to the user and bump the .so version
>>> number to 2.0.0 (as already implemented by Fedora)
>>> to clear up the situation again.
>>>
>>> Thanks,
>>>   
>>>       
>> Yes, there is merit in that, unless others have a issue with that I will
>> move 2.2.15 to 2.3.0 when it gets to the release.
>>     
>
> Thanks, that would make things a lot easier.
>
>   
>> If it helps, odbc_config in 2,2,14 and later allows checking of the
>> sizeof( SQLLEN ).
>>     
>
> Not really: We deliver binaries of mxODBC to our users and the loading
> of unixODBC happens at Python module load time.
>
> We'd rather not have to spawn an external process in order to detect
> the configuration.
>
>   
>> BTW Mark, I have just commited a fix to 2.2.15pre that solves a python
>> related issue, but I dont know if it affected mxODBC
>>     
>
> Do we have to get that from CVS or the FTP server ?
>   
FTP, or now SVN, SVN has got what hopefully will become 2.3.0

-- 
Nick
_______________________________________________
unixODBC-dev mailing list
[email protected]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.