Adriano, PS. Good questions Geoff!
> > While on this sort of subject are you able to offer any > > information about what happens to API text such as SQL > > statements and the like) sent to the server? (And details > > like relation names etc returned to the client.) > > > They're interpreted in the client charset and converted (by rules above) > to unicode_fss for storage. Where does the interpretation into the client charset take place? I've noticed the length returned when querying metadata names is 93 bytes. I presume this is actually intended to store 31 characters of Unicode_fss. So, when querying metadata directly, it should be decoded as Unicode_fss? > > There would appear to be potential complications with literal > > cast requests (eg: _ISO8859_1'abc') in connections using other > > UTF8 or other character sets etc. (Wondering if the client > > interface is expected to deal with such things - when asking > > for user input - or whether the server handles them in some > > vaguely sensible way (I suspect there is not always a good > > solution).) > > In 2.5 the problems with introducer is fixed transforming the string (in > memory for monitoring and in metadata) to x'HEXSTRING', so it's always > ASCII-compatible. How could this affect my layer of code that wraps the API? Do I need to be looking for a certain format in anything and doing more interpretation of results? Thanks, Jason LeRoy Wharton www.ibobjects.com ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
