FreeTDS Development Group

[Michael Peppler <mpeppler AT bluewin.ch>]

On Mon, 2003-07-07 at 22:33, Brian Bruns wrote:
> 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.

Yes - but the messages generated by OpenClient don't use the same
numbering scheme as the server messages, and are sent to the CLIENT
callback (in CTlib) or the error handler (in DBlib).

Michael

> 
> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds