FreeTDS Development Group

[Peter Deacon <peterd AT iea-software.com>]

Hi there.

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.

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'.

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

numRecord should be decremented after NO_DATA_FOUND check.

Misc:
Return 'Microsoft SQL Server' if using MSSQL from SQLGetInfo

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'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?

Anyway have a few weird bits left to check into before posting my diff.

You have no idea how cool this is :)

Thanks everyone
-Peter