FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

Actually, there are lots of messages generated directly from the client
libraries (meaning in Sybase OpenClient).  "Attempt to initiate new query
with results pending", datatype conversion errors, some bcp stuff all come
to mind.  I think it's probably an ok way to deal with it.

Mind you, that's not an excemption from return a FAIL where appropriate, but
in this case with a dbnextrow() and a partial failure (some data
translated, some didn't...not an outright failure) i think it's the best we
could hope for.

Brian

On Mon, 7 Jul 2003, Peter Deacon wrote:

> On Mon, 7 Jul 2003, Lowden, James K wrote:
>
> > All,
> > Befitting the date, on 4 July I committed changes that enable FreeTDS to
> > convert UCS-2 data to/from ISO-8859-1 or ASCII without libiconv.
> > Functionally, this restores the status quo ante; our recent libiconv
> > dependency was an accident that's now been fixed.
>
> > There is a new feature concerning how related errors are handled.  If we
> > cannot convert data on the way to the server, we emit message 2402 and
> > return an error.  If we cannot convert data on the way to the client, we
> > emit message 2403 as a warning, and replace each unconvertible character
> > with '?'.  The error numbers, text, and severity emulate the messages
> > emitted by Sybase servers in similar situations.  FreeTDS also emits
> > messages 2401 and 2400 (which afaik Sybase does not) to indicate
> > insufficient buffer space.
>
> IMHO native errors should pry only be set by the RDBMS... That way you can
> tell the difference between a driver vs database problem.  But that's a
> generalization.. I dunno if it's the right thing to do in this case.
>
> Instead we might set a sqlstate code to indicate character set problems.
> Looking around 2402 and 2403 are not in MSSQLs message catalog.
>
> > There were two internal modifications of potential interest.  One,
> > tds_iconv() got a new signature which proved easier to work with than its
> > first incarnation.  Two, if no libiconv is detected, we rely on our
> > simple-minded built-in replacement.
>
> ::)
>
> take care,
> Peter
>
> > We are now positioned to complete the work of handling per-column
> > conversions (TDS 8.0) and cleaning up the UCS-2 assumptions in parts of
> > libtds.  These should lead to continued progress toward complete support 
> > for
> > UTF-8 clients.
> >
> > I would be very glad for any feedback on snapshots that include these
> > changes, especially on big endian or 64-bit clients (neither of which I
> > own).
> >
> > Looking over TODO, I see we've addressed the better part of the iconv
> > issues.  As I see it, things are stabilizing further; the list of broken
> > things is getting shorter again.  That bodes well for a 0.62 release in 
> > the
> > fall.
> >
> > May all your data be normal.
> >
> > --jkl