Re: ODBC Driver

On Tue, 5 Oct 2010, Frediano Ziglio wrote:

> Ehmmm... I don't know why but this was in my outgoing folder since 
> 2003... and yesterday my e-mail client decided to send it!

I think this is an omen to get me to finish my transport patches. :)

regards,
Peter

> 2010/10/4 Frediano Ziglio <[email protected]>
>
>> Il sab, 2003-03-22 alle 02:41, Peter Deacon ha scritto:
>>> Hi there.
>>
>> Hi Peter.
>>
>>> Grabed the latest freetds snapshot yesterday.  In a few hours I managed
>> to
>>> get ODBC driver working darn near perfect... Thought for sure it would
>>> take weeks of hacking before I'd even be able to login let alone do
>>> anything useful.
>>>
>>> We've played with several third party ODBC drivers for MSSQL
>>> and Sybase over the years and I've gotta say from what I've seen so far
>>> FreeTDS is second only to Merant/Data direct/ whatever their called
>> today.
>>
>> Thanks
>>
>>> Best of all, there was already a visual studio project in the tarball..
>>> all I had to do was compile.. Nothing like being able to step from
>>> your application right into the driver (Edit and continue anyone?:)
>>>
>>> Heres what I've found so far..
>>>
>>> When we call stored procedures have a habbit of using caps to spell out
>>> CALL.  The prepare routine would fail if not all lowercase 'call'.
>>
>> Fixed in CVS
>>
>>> For SQLGetDiagField
>>> Implemented:
>>>       SQL_DIAG_ROW_COUNT
>>>       SQL_DIAG_CLASS_ORIGIN
>>>       SQL_DIAG_SS_MSGSTATE (The SS functions I set win32 only)
>>>       SQL_DIAG_SS_LINE
>>>       SQL_DIAG_NATIVE
>>>       SQL_DIAG_SQLSTATE
>>
>> Good!
>>
>>> numRecord should be decremented after NO_DATA_FOUND check.
>>
>> Fixed in CVS (with another problem...).
>>
>>> Misc:
>>> Return 'Microsoft SQL Server' if using MSSQL from SQLGetInfo
>>
>> Fixed in CVS.
>>
>>> With text datatypes there was an off by one.. It would move the value
>>> pointer back one making the first letter garbage and exclude the
>>> last.
>>
>> I didn't understand...
>>
>>> I've always wondered about where SQLStates come from.  Sybase stores a
>> few
>>> in their sysmessages table however as far as I can tell they don't exist
>>> in the MS sysmessages table.   Cought the bits in freetds where it can
>>> fetch sqlstates from the wire..but it never appears to get called.  If
>>> sqlstate is not otherwise set added lookup tables for MSSQL and Sybase
>>> which map about 150 native errors to SQL States..  Hope this sounds
>>> reasonable?
>>
>> No, simply sql server return sql state itself. Perhaps libtds discard
>> this information... Another problem is translation from odbc2 codes to
>> odbc3 codes...
>>
>>> Anyway have a few weird bits left to check into before posting my diff.
>>
>> Well, post your diff.
>>
>>> You have no idea how cool this is :)
>>>
>>> Thanks everyone
>>> -Peter
>>
>>  Frediano Ziglio
>>
>>
>>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>