FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2009/3/10 James K. Lowden <jklowden AT freetds.org>:
> Frediano Ziglio wrote:
>> do we have any stopover for next release?
>
> Hi Freddy,
>
> I wasn't thinking about a new release.  Any particular reason you want one
> soon?  I think there's work to do.
>

Mainly I can see
- bcp improvement
- odbc parameters
- odbc wide character support
- better odbc error report
- odbc tests updates (style and improvements)
not that much but importants

> I'm partway toward:
>
> 1.  Separating connect and login.  I want the messages to be clear as to
> whether the connection failed or the login failed.  IIRC error handling
> doesn't work at the very earliest stages.  "Server SYBASE not found" must
> die.
>

Mmm... I agree... some days ago I found that tds_read_interfaces
(config.c) at the end try to use servername as hostname... perhaps is
better to move this code in another function (tds_read_servername....
uhm... ugly) and return "not found" from tds_read_interfaces.
Another problem is name resolution. Personally I don't like host name
resolution in config.c... I would prefer in net.c and during
connection, not during configuration reading (it seems more correct).

> 2.  TDSVER = auto.  I want this to be the default.
>

ok, are you satisfied with current implementation?? I think it's ok
for mssql but not that much for Sybase... sybase use mainly 5.0 and
also don't use browser to discover port and moving from 7.2... 7.1...
7.0... 5.0 ! is a bit slow. I think usually people that use Sybase
HAVE to know port so perhaps a rule like "try 5.0 first if port is
specified" would help... but slow down mssql connections. Perhaps one
could object that if somebody wants fast connection could set
parameters fixed (specify port and protocol)....

> 3.  A better form of tsql -L.
>
> 4.  Modifying instance-name lookup to use bind/listen instead of 16
> attempts.
>

I replicate mssql client way...

> 5.  Making db-lib unit tests portable and testing them on all three
> platforms.  We should do the same with the others, too.
>

What do you mean by "portable" ?? Three platforms ?? Linux, Windows and ??

> I've made no progress on:
>
> 1.  Fixing BCP to make file-encoding a property of the file, not of the
> connection environment.  (LANG might not agree with a file's encoding.)
>

I was not aware of this problem...

> 2.  The most important db-lib bug, reported a few months ago.  Under
> certain circumstances, it apparently ignores resultsets.  I haven't got a
> good unit test for it, and I don't know if the vendor implementations
> behave the same or differently.
>

?? I don't remember ?? We got a report from ML I imagine...

> 3.  Reducing memory requirements for TEXT/IMAGE columns when querying.
>

limiting text store into rows?? I think this could be posted to a
future release. Personally I don't like the way BLOB are handled.
Looking at the code you can find a lot of rows that test for BLOBs
(is_blob_type) and read TDSBLOB->textvalue from column_data. I think
it would be more readable to see only column_data...

> Finally, I need to upgrade the autotools that generate the distribution
> tarball.  I think that will help our OS X and maybe AIX friends.  I would
> like to do that well in advance of a release to give people a chance to
> complain^W report problems.
>
> I suppose we don't have to do all those things.  But it would be nice to
> finish the partly-done list and upgrade the autotools.
>

Ok, I hope it will help

Frediano