From: Ivan P. <Iva...@se...> - 2004-04-08 19:54:12
|
> From: "Peter Jacobi" <pj...@wa...> > Hi Ivan, All, > > I agree with most of your analysis, but > want to remark on two points: > > "Ivan Prenosil" <Iva...@se...> wrote: > [...] > > Both input and output parameters contain information about > > character set (in xsqlda structure, on per-column basis), > > so I do not understand why Firebird insists on translating > > them at all. > > Because only FB server can do the right transcoding? In strange > cases only calling fbintl*.dll will give the correct charset transcoding. > So client side charset transcoding may differ subtly from FB's one > and that can introduce problems. Yes, it would be nice if you could ask FB to do transcoding if you want it, but it is bad if it insists to do it always. Is not this the whole problem ? > > Moreover, informations in xsqlda are not correct imho: > > if I connect using WIN1252 character set, and select from column > > defined using ISO8859_1 character set, then data are returned > > converted to connection charset (WIN1252), but information in xsqlda > > says that it is ISO8895_1. > > Disagree. The client already knows which charset the data travels > over the wire (its conn charset), the info xsqlda informs the client, > which character repertoire the columns can accept. Agree, this is one of possible points of view. The other is - coercing data types. It is possible to select e.g. from date field, but change data type in xsqlda to varchar; FB will do the conversion; or change smallint to int, or int to double precision etc. Why should not the same be possible with character sets ? Ivan |