Wrong field types with UseUnicode and non-UTF8 fields

[Wade]

Driver 2.50.20
FB 2.1

If I create a database with no default character set, and as such:

CREATE TABLE TEST1 (
DESCRIPTION1 VARCHAR(10) CHARACTER SET UTF8,
DESCRIPTION2 VARCHAR(10),
DESCRIPTION3 CHAR
);

Then for the driver I set UseUnocode=True, ALL THREE fields are created as TWideStringField (with the correct sizes: 10, 10, 1) however as the second and third fields are not using a character set that can store other than ASCII, they should be created as TStringField.

After the 3 TWideStringField fields are created, then say in DESCRIPTION2 I store some non-ascii characters, they are stored and retrieved by dbxida as entered but the data in the database is not correct (view it using isql or anything that knows that the field is not UTF8).

In this case, surely the second and third fields should be created as TStringField and any non-ascii characters should be lost/converted in the normal manner when converting to an ansii string.

[Plash]

If the character set of a field is NONE, the real character set is unknown. This field can store data in any character set (including UTF8). So DbxIda creates TWideStringField.

To store data as ASCII, set the character set of the field to ASCII or WIN1252. In this case DbxIda also creates TWideStringField but data are converted to the field character set when they are saved.

[Wade]

So, if the dabase default character set is ASCII then "unspecified" fields will use character set ASCII (or alternatively specify the character set as ACSII on "non-unicode" fields).

In this case, why does DBXIDA not create a TStringField rather than a TWideStringField for those fields with character set ASCII?

[Plash]

The character set used in TStringField depends on Windows regional settings. So both TStringField and TWideStringField can contain non-English characters.

TWideStringField is used for any character set when UseUnicode=True because many character sets cannot be represented in TStringField (not only UTF8).