Skip to Content.
Sympa Menu

freetds - Re: [freetds] Problem with current snapshot

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Problem with current snapshot
  • Date: Thu, 13 Nov 2003 23:15:30 -0500

On Thu, 13 Nov 2003, "Simon Talbot" <simont AT nse.co.uk> wrote:
> Yes, I thought exactly what you said, that the matching of character
> sets is preventing the code which is erroneous being entered -- would
> you like me to take my testing any further ?

Can I take a rain check?

I'm not sure single-byte <-> single-byte conversions are expected to work
correctly yet. Frediano has dropped a lot of code in, and I'm behind the
curve at the moment. We're certainly not completely ready, because there
are definitely parts of the code that are not yet relying on the
per-column encoding information.

(TDS 8.0 transmits encoding metadata for each column of character data.
Our internal structure supports that now. For other TDS versions, we
populate (or mean to) each column's encoding information with a pointer to
the connection's encoding. That way, the convert-or-not decision can
always be made per-column, regardless of the TDS version currently
employed. But I don't think every such decision has been rewritten to
take advantage of the per-column information.)

> Also I note that the current snapshot is about 10-15% slower than 0.61.2
> with exactly the same application and data (produces identical results).
> Is this to be expected at this stage of development, ie. Is there a lot
> of debug floating around ?

Er, well, maybe. 15% sounds like logging. There's a lot more logging
going on nowadays.

We do more internal lookups and buffer copies for iconv, but we've also
removed some in the name of Signor Frediano "Efficiency" Ziglio. But you
can do buffer copies on twelve continents before they add up to 10%. The
database is orders of magnitude slower.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page