Using table language drivers versus global language drivers
When the language driver of a table differs from the current global language driver, the table language driver is loaded into memory automatically when you open the table. Thereafter, the table language driver is respected by some commands, while the global language driver is respected by others.
All commands that have nothing to do with a table use the global language drivers. The following table shows the general rules when operations are performed on table data where the table language driver differs from the global language driver.
Table driver |
Global driver |
INDEX ON command expressions |
SET FILTER command expression
|
FOR scope expression of INDEX ON command |
FOR and WHILE expressions for every command except INDEX ON
|
SET KEY range checking expression |
SET RELATION TO expression |
SORT command expressions |
|
Secondary matches for expressions in LOOKUP( ), FIND, SEEK, and SEEK( ) with EXACT set OFF |
|
Secondary matches for SET RELATION TO expression with EXACT set OFF (uses the driver of the child table) |
|
For example, when you create a table file with the German language driver, an LDID identifier is written to the header region of the file. If the global language driver is set to English and you open the table in dBASE Plus, it notes the discrepancy between the table’s and the system’s language rules. If you create an index with INDEX ON, the logical order of the index obeys the language driver of the table:
use VOLK // Created with the German language driver
index on NAMEN tag DIENAMEN // Orders records in the German way
By contrast, if you create a filter with SET FILTER, the filtering condition obeys the global language driver:
use VOLK
set filter to NAMEN = "KONIG" // Excludes records with "KÖNIG" in NAMEN