buppcpp wrote:

> But when you are use ADO, ODBC, etc.. within Borland Products and
> you do something like:
>
> if (FieldByName("rdb$relation_name")->AsString == "STORE_NO")
>
> It fails.
>
> This seems like an unnecessary burden, that could be easily fixed by
> defining the system tables as VARCHAR instead of CHAR.

There are a bunch of problem with system object names. For one, they're
way far too short. For another, some names are automatically generated
from other names, and if the base name is full size, the generated name
doesn't fit. For another although they're nominally UNICODE_FSS,
they're limited to 31 bytes, not 31 characters. For another, they
indicate whether the object uses a quoted identifier by the presence of
a value that can't be a non-quoted identifier. At least the [ugly
stupid] trailing spaces can be eliminated with single function call.

That whole area needs a thorough scrub, and incremental fixes that break
backward compatibility without addressing the whole problem aren't
appealing - at least to me. The new record encoding being discussed on
the architecture list would allow arbitrarily long strings. We can
[should?] recognize that the performance saving of upcasing names when
they are stored is no longer measurable and store what is entered... and
so on.

Regards,


Ann