FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il ven, 2003-04-11 alle 10:48, Thompson, Bill D (London) ha scritto:
> Brian, James - thanks for the input. I'll mull it over some more.
> 
> A few (failry random) points...
> 
> Whatever's done, I'm keen to minimise disruption to the dblibrary
> functionality.
> 
> Could we code a new version of the tds results/row processing that could
> live alongside the existing functions temporarily ?
> 
> I disagree with Brian's point on MS TDS - I think that they'll leave TDS
> alone pretty much.
> I base this view on what's happened with server side cursors: Whereas Sybase
> added significantly on to the TDS protocol to support this functionality,
> coding a whole new raft of messages, MS preferred to use the existing
> protocol to execute "pseudo system stored procedures" - sp_cursor and
> friends. I think they would go with this approach for any further additions.
> 
> Could Freddy give us a view on the odbc API in this area ? is it well
> serviced by the existing TDS functions ? are there any problem areas or code
> that you regard as "fudged" due to inadequacies in the TDS layer ?
> 
> Bill

I think libTDS is very important. IMHO ctlib won't be our libtds. There
are some difference that require a different library. For example
ct_lang_param do not exists in tds7+, so it should be emulated inside
ctlib. Another difference is convert setting. In ctlib I can set a
conversion and library will use this function to convert type.

I'll describe my ideal method. 

A function do not have correct behavior? 
1- write a new unit test (the function should work in such way)
2- try to fix the problem inside high-level library
3- if this is very difficult and rewriting some libtds is easier try to
change libtds
4- execute all unit tests (just a make check from freetds root)

If you aren't able to pass step 3 and 4 discuss in mailing list and find
a solution that suit all libraries.

If step 4 pass but some bug raise in some library this mean that there
was no sufficient unit tests for this library. The library maintainer
should reiterate with his library starting from step 1.

This is why I execute all unit tests before every (unless comments or
warning remove) commit.

freddy77