FreeTDS Development Group

["Magnus Ahl" <Magnus.Ahl AT infogate.se>]

James K. Lowden wrote:

> I have a little write-up on that.  It might help.
>
> http://home.schemamania.org/projects/freetds/doc/which_api.html

        Excelent. I wish this had been in the FAQ earlier, mildening
        the confusion. But there still needs more "sqldb for dummies"
        for finding the propper dblib definition, a test example for
        each library, "where do i find the files in my system" and
        "now, how do i compile this stuff".

        Right now i'm looking att the dblib unit tests to try to figure
        out the programming flow. ;-)

        Well, got it working. Really easy. < 30 minutes. ;-)


> Because your target is Microsoft, I recommend db-lib (so you can compare
> with their implementation) with one important caveat.  db-lib connection
> cannot be multiplexed.  I mean: On any single connection, you must
> completely read or cancel the results of one query before you can start
> another.  Most databases don't work that way, and IIRC MySQL doesn't work
> that way.  db-lib applications open a seperate connection to the server
> for every concurrent query.

        Well, we intend to create our own connection pooling anyway so that
        will not be a huge problem. MySQL is memory-intense in the sense that
        it reads all data to memory and then give you static char pointers
        back. This we have to solve in respect to TDS more network-type
        fashion of "get the stuff over the wire as fast as possible", probaby
        by creating our own subclass containing resultsets. All our programs
        is Open_query->Get_result->Close_query in a very linear fashion.


> > 4. Is there really no way of getting the affected rows from the server
> > before traversing the results? Right now we are doing the same query two
> > times to mimic the get_affected_rows() library call that exists in
> > MySQL. All structures I have traced trough (TDSSOCKET->rows_affected and
> > TDSRESULTINFO->row_count for example) always returns "1" or "0".
>
> No, there is not.  It's a "feature" of TDS: the server begins sending rows
> as soon as they start to become available, before the last row is known
> even to the server.  It counts them "on the way out the door", so it can't
> tell you how many there were until they all have left.
> If you plant STL collections atop db-lib, you can do a lot of work without
> worrying about rowcounts in advance.  That's what I do.

        That explains it. And it sounds like a good plan. We probably will
        implement a subclass to handle the (somtimes multiple) resulsets
        using STL.


> Hoppas det hjälper er att tänka på FreeTDS.  Har det så bra.

        Thanks, we will.


> P.S. Any chance your class library could become part of FreeTDS?  Just
> asking...

        We will (if we will be trusted with CVS write access *smile*) check in
        any contributions to the Windows build. It is in our intrest to keep
        the library working on Windows so that we seamlessly can checkout and
        keep developing new versions of our product, as the releases towards
        FreeTDS version 1.0 continues.

        Regarding the C++ class, i think our specific implementatin will be
        very much written for our product. We will, for example, not implement
        UNICODE support since the rest of our product only handles iso-8859-1,
        and we will only support "Europeean dates".

        I will check with my bosses if we can contribute the C++ framework 
back
        to you, for ideas and perhaps adoptations of the code. But it will be 
a
        judgement call from the FreeTDS developers side if you want to use it.



 Infogate AB             Magnus.Ahl AT infogate.se
 Storgatan 29                   tel: 035-171970
 Box 345                      mobil: 702-118265
 301 08 Halmstad                www.infogate.se