[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    [freetds] Re: Starting to use FreeTDS
From:       "Magnus Ahl" <Magnus.Ahl () infogate ! se>
Date:       2002-09-12 9:25:52
[Download RAW message or body]


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@infogate.se
 Storgatan 29                   tel: 035-171970
 Box 345                      mobil: 702-118265
 301 08 Halmstad                www.infogate.se


---
You are currently subscribed to freetds as: [freetds@progressive-comp.com]
To unsubscribe, forward this message to leave-freetds-113879Q@franklin.oit.unc.edu
[prev in list] [next in list] [prev in thread] [next in thread]