One of the things that developers in the past have not always been very aware of (particularly developers in the US), are the language drivers used to handle sorting and displaying of characters in their tables.
dBASE for DOS applications used (for the most part) ASCII as the basis for the language drivers, and there were a set of drivers for various actual languages, which included character set mappings for specific languages, as defined by DOS. (Indeed, many developers kept (or may still keep) an ASCII chart handy ...)
Many people have gotten confused when they got into Visual dBASE, because if they tried to display a value using CHR( n ) (where 'n' is some number in the ASCII table), the character sometimes does not display what they expect, especially if the character has a numeric value of 128 or greater.
This is because Windows uses ANSI as the standard character set, and therefore most Windows fonts (most of the TrueType fonts in particular) use a different character mapping than ASCII.
In the DOS world, setting up the language drivers was usually done on installation (although there is a setup utility that let you change this). In the Windows world, it is done via the BDE (Borland Database Engine). In either case, the language driver name used when creating the table is stored in the table's header.
If you set the BDE to one language driver, and use a table that was designed using a different language driver, the default settings in Visual dBASE will tell you that there is a "Language Driver Mismatch". Is this serious?
Well, no. Not really. You can tell dBASE to not tell you about it (Properties menu, Desktop Properties, Country Tab, uncheck "Alert on mismatch" checkbox, click "OK", alternatively at the command window, type: SET LDCHECK OFF -- make sure that your application's .INI has the appropriate setting), and when using a table with a different language driver than your (current) default (as set in the BDE) will not be any trouble -- the language driver for that table will be used, as long as it can be found.
The real problem is that if you want to use some of the upper characters in the character set, they are mapped very different from the DOS world, and you may not be getting what you thought you would be ...
It is recommended that you set up the BDE to use ANSI characters. Very few of the TrueType fonts in Windows (of any flavor) use the old ASCII character map (MicroSoft has a Line Draw font that is installed with Word, which can handle line drawing ...).
In some versions of the BDE (4.5 and 5.0), there are problems with the US ANSI driver. I have never had a problem using the "W Europe ANSI" language driver. It always works for me, I have never had problems sorting data, finding data, etc. I even use a lot of the upper ANSI characters (ones with diacriticals -- umlauts, accents, accent graves, etc.).
As a side note, for whatever reason, when the BDE is installed with Visual dBASE 7.x, the default table driver is set to "Paradox", and the default language driver to "Paradox ANSI". If you bring up the BDE Administrator, you can change this:
Click on
the Configuration tab
Open "Configuration"
Open "System"
Click on INIT
Set "Default Driver" to "dBASE"
Set "LANGDRIVER" to "'W Europe ANSI'"
Open "Drivers"
Open "Native"
Click on "DBASE"
Select "LANGDRIVER" and set to "'W Europe
ANSI'"
Press CTRL+A (and answer "Yes" to the question
about applying changes)
Close the BDE Administrator
The next time you load Visual dBASE, you will be using the W Europe ANSI driver, and any new tables created will automatically use that driver as part of their definition.
(NOTE: if you are developing for European applications, you will probably wish to use language specific drivers ... you are likely to be more aware of which you need to use than I am -- change the instructions above to match the driver you need, but by all means, use the ANSI driver, not the ASCII ...)
Whether or not you set the BDE to
ANSI drivers, you may find some difficulties when working in Windows because
some characters may get changed ... if you set the BDE to use an ASCII driver,
then this becomes very difficult. The source editor will translate characters
that you may have displayed properly in a form (when you edit the form in the
source editor) out to the wrong version. There is a fix you should add to your
VDB.INI file that will solve any issues here:
[CommandSettings]
LDRIVER=WINDOWS
This setting will ensure that the source editor does not change those characters for you ... it will always assume ANSI, which is what Windows uses. NOTE: if you already have a "CommandSettings" section in the .INI, just add the "LDRIVER" line)
How do you CHANGE the driver of a table? That's a bit more difficult. It should be possible, using low-level functions in dBASE, to change the header in a table so it is using the correct language driver.
A simpler solution is to create a new table with the same design (field names, types, sizes) and use the old XBase DML commands to append all rows from the original table to the new one.
USE newtablename
APPEND FROM oldtablename
USE
One way to see what the language driver is of a specific table is to use the undocumented TableDef class -- it will show you the language driver the table was created with:
t = new TableDef()
t.tableName = "TableName"
t.load()
? t.language
If you get something like "dBASE ENU cp437", the table is using an older ASCII driver ... (ENU = ENglish, US ...)
The only reason to need to change the driver for a table to ANSI is if you are using the upper ANSI characters (anything > 127). If you change the setting in the BDE, you will have access to those characters, but if you try to store, say, an o with an umlaut (" -- or ö), to the table, you may get strange results. The ASCII driver will not map the character to the same location, and so the ANSI character (which maps to 0246) will appear as a division symbol (which I don't know if there's an ANSI equivalent of ...).
In a case like this, you would want to change the driver. Otherwise, you can probably not worry about it.