Re: Representing data on disk in an MV database - was Re: foundations of relational theory? - some references for the truly starving

"Jonathan Leffler" <jleffler_at_earthlink.net> wrote in message news:l72mb.4070$wc3.1528_at_newsread3.news.pas.earthlink.net...
> If you want to discuss the wisdom of using those markers, you might
> ask how an MV database stores Turkish names which use the y-umlaut
> character, because that is coded as 0xFF or 255 in the ISO Latin-1
> character set. And similarly for the other mark bytes. That advances
> the discussion constructively and makes use (rather than abuse) of the
> bandwidth - of both the Internet and the people reading this group.
>
Gosh Jonathan you're just cutting straight to the chase - bravo!

This is an interesting point - I'll be speaking from a purely PC (well strictly speaking ASCII) perspective here. When Revelation (and thinking about it PICK) was first introduced ASCII had defined char 0- char 127 so anything over 127 was fair game. Back then umlauts etc mapped lower down the ASCII scale and 247+ were essentaillay graphics characters so this was not an issue. With the introduction of Windows PCs moved to ANSI and suddenly these delimiters stopped working in Turkisk, German, Finnish et al.

The initial reaction from Revelation at least was to introduce "CHARMAPPING" where the system would allow you to map these characters onto unused characters in the ANSI sequence. This then transparently changed things around so that you were never aware of the restriction. Newer releases of OpenInsight use UTF8 Unicode to map these delimiters to other things for disk storage so that again the user never sees it as an issue. Received on Fri Oct 24 2003 - 09:28:28 CEST