FreeTDS Development Group

[LacaK <lacak AT zoznam.sk>]

Hi,
To get positive example feedback:
We use FreeTDS db-lib as client library with FreePascal/Lazarus sqlDB 
components to connect to MS SQL Servers and Sybase.
We use already TDS 7.3 new data types, so we are in line with current 
FreeTDS.
-Laco.

> Great work on the new release, Freddy!
> Reading about James retiring earlier this year made me feel all nostalgic. 
> Eventually it grew into this strange curiosity to once again see what using 
> FreeTDS and SQL Server are like these days, rather than just passively 
> hanging around on the mailing list.
>
> So I ended up installing a copy of SQL Server 2014 and keeping up to date 
> with your changes the past couple of weeks. I've been playing around with 
> them and testing many things, both on Mac and Linux, and I have to agree: 
> FreeTDS feels ready for a new release.
> It's very satisfying to store and retrieve emojis. 😃
>
> The one repeating issue I kept running into is that, unfortunately, FreeTDS 
> really is only the first part of the puzzle for even most developer end 
> users. It's so easy to wrongly assume that problems start or end with FreeTDS 
> when, in fact, the library was fine all along, and the problems are further 
> up the chain. I can only hope a new release of FreeTDS will also spur the 
> developers of dependent software to issue some long-overdue updates.
>
> Sqsh is still stuck at no higher than TDS 7.1, or it would try and malloc 
> (unsigned)-1 for any VARCHAR(MAX) column. TDS 7.3 won't actually be usable by 
> anything interfacing with dblib or ctlib until they too add support for the 
> SYBMSDATE / SYBMSTIME / SYBMSDATETIME2 / SYBMSDATETIMEOFFSET types. And PHP's 
> pdo_odbc is in an especially sad state that makes it practically unfeasible. 
> Rather disheartening to see bugs reported against it 7 years ago seeing no 
> improvement still.
>
> One thing that did work better with Microsoft's binary-only 2013 release of 
> “Microsoft ODBC Driver 11 for SQL Server on Linux” is that it supports 
> binding UTF-8 input parameters as SQL_C_CHAR which will then survive a trip 
> to an NVARCHAR column server-side to be stored as UTF-16.
> FreeTDS instead insists on immediately trying to iconv the UTF-8 to CP1252 
> (my SQL Server's single-byte encoding).
> I did note that this already seems to be on your TODO wishlist, and that even 
> this could work through FreeTDS if only the clients used WCHARs instead.
>
> > On Mar 23, 2015, at 19:55, Frediano Ziglio <freddy77 AT gmail.com> wrote:
> >
> > Hi,
> >   although there is no dates planned nor any release
> > candidate/beta/alpha/whatever my TODO list for the release is getting
> > shorter! As somebody would have noted I mostly updated documentation
> > to reflect changes.
> >
> > The only big point left is SSL certificate check (there are no code at
> > all although I'll have a look at curl implementation and there are
> > explanation on how to test). I want this in the release as it is a no
> > back compatible change so is better to have in a release.
> >
> > Any help or test is really appreciated.
> >
> > Frediano
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds