Jim Starkey wrote:

>Of course not. Fixed length strings aren't a Java concept (hurray for
>Java!). The engine and tools, however, have 31 character identifiers
>hard coded in a thousand places. These need to be phased out in favor
>of a string class.
>
>

This job is 50% done in firebird2 codebase. jrd directory is cleaned
(certainly, I might miss some places). Class internals should be changed
to support long identifiers,
but thousands of places inside the code already use class MetaName to
work with identifiers.

>The existing remote protocol is based on fixed length strings. We need
>to get away from that as well (the new record encoding is the answer).
>But the larger question is API, on the internals.
>
>

I've made a look at IscDbc. It's fine, when you plan to write end-user
program, using API.
But I'm sure, that >90% of programs are now written, not using low-level
API, but some tools
of visual programming like Delphi. And for writing low-level routines
for such tools (like
components in Delphi) SQLDA API is much better tool.
Anyway we will have to support it for compatibility. Therefore what a
problems extending it
with new SQLDA version?

>>Just that one part of the world accidentaly got 1 byte per char, while
>>other needs 2 bytes per char :)
>>
>>
>>
>>
>Life is unfair. Get used to it. Would you be happier if we made every
>character use 2 bytes like Java? If we did a statistical analysis of
>the (non-Chinese) world's character flows and designed an ad hoc
>compression scheme, it wouldn't be much different from UTF-8.
>
>We've been over this a number of times. The argument that although
>everyone benefits some people benefit more isn't a very good one.
>
>
>

What should happen with old UDFs, that use ASCII strings?