> Character Set and Collation are both set to NONE.

That's a bad idea, if you expect a proper sort order,
whatever "proper" means in that context here.

Rule number one. When creating a database, use a character
set, for example ISO8859_1.

Rule number two. Use that character set when connecting
to the database. IBO, FIBPlus, IBX, JayBird, ... provide
something for that.

Rule number three. Use a proper (3 byte) collation for
character fields, if you want to have a meaningful sort
order. For instance, in the German speaking area (that
won't be helpful, I guess), DE_DE is the favourite.

You can query the available collations for a particular
character set with something like that.

select rdb$collation_name from RDB$COLLATIONS where rdb$character_set_id = 21

21 is the character set id of ISO8859_1.

Be aware, when using a 3 byte collation (3 bytes needed
to store one character), then the max. key size length
cuts down to something like 84 characters, that means,
you can't index a VARCHAR(85) if you've used a 3 byte
collation when creating that field.

But, you still can supply a collation in the ORDER BY
clause, if it is a valid collation, for the character
set the field was created with.

For example, YOURFIELD was created with character set
ISO8859_1:

SELECT * FROM YOURTABLE ORDER BY (YOURFIELD COLLATE DE_DE)


Your next question might be, if you can migrate your
existing database from NONE to something else? You'd
best extracting the metadata of the database, create
a fresh database with the proper character set and
collation at field level and pump data from your old
into the new database.

HTH,
Thomas Steinmaurer
LogManager Serie - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database and MS SQL Server
Upscene Productions
http://www.upscene.com