System and method for national language support6507813Abstract The present invention comprises a National Language Support (NLS) system with Language Driver Identifiers (LDIDs) embedded as locale-specific descriptors within data objects. The Identifiers, which may be in the form of a system-comparable ID (e.g., ID byte), are employed by the system in several places to record the particular language (driver) which was used when a given data object was created or modified. The LDID methodology of the present invention allows the system to intelligently process data objects created or modified under one language driver with those created or modified by a different language driver. In the event of incompatibilities, the system provides error handling routines, including a preferred interface for warning users of incompatibilities and receiving user choices in response thereof. Claims What is claimed is:
Value Language Driver
1 US
2 INTL
3 JAPANESE
4 NORDAN
5 NORDAN4
6 SWEDFIN
wherein the language driver is used for NLS configurations. 9. The method of claim 1, wherein each identifier specifies a language driver by storing a value selected from one of:
Value Language Driver
7 ARABIC
8 DANISH
9 DUTCH
10 DUTCH2
11 FINNISH
12 FINNISH2
13 FRENCH
14 FRENCH2
15 GERMAN
16 GERMAN2
17 ITALIAN
18 ITALIAN2
19 JAPANESE
20 SPANISH2
21 SWEDISH
22 SWEDISH2
23 NORWEGIAN
24 SPANISH
25 UK
26 UK2
27 US
28 FRENCHCAN
29 FRENCHCAN2
30 FRENCHCAN3
31 CZECH
32 CZECH2
33 GREEK
34 HUNGARIAN
35 POLISH
36 PORTUGUESE
37 PORTUGUESE2
38 RUSSIAN
where the language driver is used for NLS configurations. 10. The method of claim 1, wherein each identifier specifies a language driver by storing a value selected from one of:
Value Language Driver
39 DANISH
40 DUTCH
41 FINNISH
42 FRENCH
43 CANADIAN
44 GERMAN
45 ICELANDIC
46 ITALIAN
47 JAPANESE
48 NORWEGIAN
49 SPANISH
50 SPANISH2
51 SWEDISH
52 UK
53 US
54 PORTUGUESE
55 US2
56 INTL
57 INTL2
58 SPANISH
59 ICELANDIC
60 INTL
61 INTL2
62 SPANISH
63 SWEDFIN
64 NORDAN4
65 NORWEGIAN2
66 DANISH2
67 ICELANDIC
68 ICELANDIC2
69 TURKISH
100 CZECH
101 CZECH2
102 POLISH
103 RUSSIAN
104 HUNGARIAN
105 GREEK
106 GREEK2
107 HEBREW
108 ARABIC
109 SLOVENE
110 TURK
111 TURK2
112 TURK3
113 BULGARlAN
114 FARSI
115 ROMANIAN
116 ARABIC
117 HEBREW
118 HEBREW2
119 HEBREW2
wherein the language driver is used for NLS configurations. 11. A computer system storing National Language Support (NLS) identifiers in data objects created under different NLS configurations, the system comprising: (a) a computer having a processor and a means for storing the data objects; (b) means for defining a plurality of identifiers indicating different NLS configurations; (c) means for assigning one of said identifiers indicating a current NLS configuration of the system to each data object created or modified by the system, wherein the assigned identifier specifies the NLS configuration of the system when each data object was created or modified by the system; (d) means for storing the assigned identifier in each data object created or modified by the system, whereby the object includes information indicating a specific NLS configuration of the system when the object was created or modified; (e) means for detecting a request to process a data object which was created or modified under a different NLS configuration than that which the system currently operates; and (f) means for comparing the stored identifier of the data object to the identifier of the NLS configuration which the system currently operates. 12. The system of claim 11, further comprising means for setting the NLS configuration which the system currently operates to match that of the data object requested to be processed. Description COPYRIGHT NOTICE
SECONDARY
COUNTRY PRIMARY CODE PAGE CODE PAGE
International 437 850
English (U.K.) 437 850
English (U.S.) 437 850
The following countries use code page 850 as their default code page under DOS 5.0. (In previous versions of DOS, all these countries used a different code page as their default.)
SECONDARY
COUNTRY PRIMARY CODE PAGE CODE PAGE
Belgium 850 437
Brazil 850 437
Denmark 850 865
Finland 850 437
France 850 437
Germany 850 437
Italy 850 437
Latin America 850 437
Netherlands 850 437
Norway 850 865
Portugal 850 860
Spain 850 437
Sweden 850 437
Switzerland 850 437
The following countries do not use code page 437 or code page 850 as their primary code page with DOS 5.0. They do, however, all use 850 as their secondary code page.
SECONDARY
COUNTRY PRIMARY CODE PAGE CODE PAGE
Canadian-French 863 850
Czechoslovakia 852 850
Hungary 852 850
Poland 852 850
Yugoslavia 852 850
Switching code pages in DOS does not automatically create the correct language tables inside application software, nor does it act to switch or otherwise update data files and other data objects. Moreover, when extended ASCII characters are used, messages which make sense under one code page may not be readable under another code page. In application software, for instance, switching a code page does not change the messages displayed by the program. Instead, special characters used by one code page are typically mapped into some appropriate alternate character drawn from the new code page. Using code page 850, for example, the character code 229 represents the character "o". When read under code page 437, however, the very same code will instead be considered a Greek sigma (.sigma.) character and will not be allowed to function as an alphabetic character. Thus in a database application, the character cannot be used to name objects, will not be properly handled by character functions (e.g., dBASE LOWER( ) function), and will not be included in the sort order (except as a graphic symbol). In addition to the foregoing problem, there are numerous other problems with operating application software with an incorrect code page (i.e., one having alphabetic tables that do not match the current OS code page). Users can, for example, enter characters that the application software will not be able to handle properly. In such an instance, the application may consider the characters as invalid alphabetic characters. As a result, the application may not calculate character/text string operations (e.g., UPPER( ) or LOWER( )) correctly. Moreover, the system may not know how to arrange these characters in alphabetical order. Existing database files, indexes, forms, reports, and labels may appear and behave differently, even in an unpredictable fashion, depending on how they were designed. Sharing a common code page is no guarantee of compatibility either. Users from different countries may have different language tables stored in language resource files of the application. Consider, for example, users in France, Germany, and Italy all using code page 850, yet employing different language tables; in such an instance, ordered lists show different results. As another example, applications often convert names of files, fields, memory variables, and the like to corresponding uppercase versions when working with and storing them; in such an instance, case is not a factor. If users include extended ASCII characters in such names, since the uppercasing rules differ from country to country, two distinct names in one country may be seen as the same name in another country. As a final example, in France, "fred" and "fred" (i.e., "fr"+CHR(130)+"d") may be seen by programs (e.g., dBASE) as "FRED". In Italy, however, "fred" is seen as "FRED", while "fred" is seen as "FRED" (i.e., "FR"+CHR(144)+"D"); in the US, the "e" character would be treated as non-alphabetic, with the result that "fred" would not be able to function as an identifier. All told, code page compatibility is but one of many considerations. B. Resources: Language Configuration Tables System 200 includes one or more translation resource (.RES) files. Within each resource file are appropriate language configuration tables and a complete set of messages for the target code page and translation. During system set up, these files serve to configure the system to match the user's primary or secondary code page, as defined by operating system (e.g., DOS 5.0). Each resource file includes an identifier for the code page and locale for which it is intended. For a system employing code pages 437 and 850 as primary and secondary code pages, for example, one resource file will include an identifier for 437 and another will include one for 850. In this manner, a development group (particularly one charged with translating) can easily decide what messages to include in each source file. In the U.S., for example, messages written for code page 437 work fine under code page 850. In other countries, however, messages written for one code page might not make sense under another code page. In such an instance, the resource file may contain a different version of the messages. In an exemplary embodiment (using the specific example of a DBMS embodiment), a translation resource file contains the following set of tables: several alphabetic tables, a box-drawing (optional) table, and a SOUNDEX (optional) table. Each will now be described in turn. Alphabetic tables provide five basic tasks: (1) Determining if a character is alphabetic. This information is helpful, for example, for functions which operate on alphabetic data (e.g., ISALPHA( ), ISUPPER( ), ISLOWER( ), the "A" picture format function, alphabetic picture template symbols, and the like found in dBASE). (2) Mapping a lowercase character into its uppercase equivalent (and vice versa). Functions which require this information include, for instance, dBASE UPPER( ), LOWER( ), the "!" picture function, as well as some picture template symbols. (3) Ordering of alphabetic characters. This is needed to SORT and INDEX data, for example, as well as for string comparisons. (4) Ordering of two-letter combinations. In Spanish, for instance, the two-letter combination of "ch" is ordered after other two-letter combinations with "c" (i.e., "cz"<"ch"<"d"). This information is stored in a "two-to-one table" (i.e., multi-letter combinations which "collapse" for purposes of ordering). (5) Ordering symbols that can be expanded to two letters. In German, for instance, the character .beta. (char code 225 in code pages 437 and 850; char code 223 on Windows ANSI/Latin-1) is appropriately treated as "ss" (i.e., a pair of lowercase "s" characters) when sorting. This information is stored in a "one-to-two table" (i.e., single letters which "expand" for purposes of ordering). The other exemplary resources include box-drawing table and SOUNDEX tables. The former tells the system which characters to use for drawing boxes and lines (e.g., for user interface). The latter tells the system what SOUNDEX values to assign to extended ASCII characters; this information is useful, for instance, for dBASE SOUNDEX( ) and DIFFERENCE( ) functions. By default, these tables are always used. C. Default configuration: LANGTABLES Setting In an exemplary embodiment, the system includes a configuration or preference file 231 (dBASE CONFIG.DB file) where users may specify system settings or "preferences." To tell the system to use the alphabetic tables, the following setting is entered in the configuration file: LANGTABLES=ON. Conversely, LANGTABLES=OFF will tell the system to employ a default (e.g., employing US tables). During system operation, users are alerted whenever they employ a data object (e.g., file or index) created under one setting of the language table (LANGTABLES), while the system is operating under another setting of the language table. In this manner, the LANGTABLES setting provides a quick method for switching to a default language resource. By defaulting to a particular setting (e.g., US), the system is always able to provide a lowest common denominator (i.e., the ability to default to a common set of data). The advantage of this approach may be seen, for instance, in a single version intended for two separate markets: the United States and the United Kingdom. For the US/UK version, the LDID stored in the resource file is preferably set to the UK language driver ID. The US language driver ID (27) is not inserted into the resource file but, instead, is indicated by a LANGTABLES OFF flag. In other words, with language tables off the US LDID is inserted into data objects which are created or modified, just as if the US LDID had been stored as a default in the resource file; the stored LDID is ignored. Moreover, the system does not rewrite the stored LDID kept in the resource file but merely overrules its value, by setting the active LDID to the value of 27 during each session of the system in which language tables is set to off. The operation of assigning the active LDID (which in the case of language tables being off is the value of 27) may be summarized by the following table.
Local
LANGTABLES Stored LDID Active LDID LDID Value
ON <stored LDID> <stored LDID> <stored LDID>
OFF <stored LDID> <default LDID> <default
LDID>
where, for example, the default LDID is US (i.e., 27). During a session of the system with language tables off, when a database file or index with a local ID of 27 is encountered, there is no language driver mismatch; both the active version of the system and the file or index have matching LDID values of 27. When a session of the system with language tables enabled encounters a database file or index with a local LDID of 27, there is a language driver mismatch (since it is not possible for the session to have an active LDID of 27 and also to have language tables on). D. Language Drivers 1. Introduction "Language drivers" are provided to correctly handle characteristics of a given language. The drivers reference a character set and a collection of tables describing the rules for that character set. For instance, language drivers include information about character sets (code pages), sorting orders, upper case and lower case rules, which characters are alphabetic, and what double-letter combination it is to accept. While the language driver for two countries may actually use the same code page, they are not necessarily the same. For instance, French, German, and Italian may all use code page 850 (or 437), yet employ different alphabetic tables, since their sorting orders differ. Language drivers are supported with language customization tables (described above) and must be used with the correct code page (from the operating system). For those readers who may be unfamiliar with the intricacies of translating information from one language to another, the following will serve as an example. Characters that are alphabetic in one code page XXX (e.g., 850) may not be alphabetic in another code page YYY (e.g., 437). Thus, a user trying to employ an index created under XXX, while running under YYY, may see what looks like graphic characters in the sorted list. Conversely, if the user creates a new index under YYY, the odd looking graphic characters end up (are sorted to) the end of the collation list, as they are not considered alphabetic characters by code page YYY. This can cause information records to be lost, particularly if the user is employing a filter which is limited to a range of character values (e.g., dBASE SET FILTER TO command). For instance, under code page 850, character code 229 plus "laf" falls within a range of records from greater or equal to "O" and less than or equal to "P" (e.g., dBASE command SET KEY TO RANGE "O", "P"). Under code page 437, however, it would no longer be in this range, since it would be near the bottom of the ordered list. Moreover, as users may include extended-ASCII characters in the names of fields, files, memory variables, menus, pop-ups, and the like, if these characters are no longer valid in another code page, the program will no longer function when a different code page is employed. For instance, a field name of character code 229 plus "laf" works fine under code page 850; however, if this field is used in a key expression, then when a 437 code page user attempts to load the database file, the system will complain of an illegal key expression (with a failure to open the database file). 2. Language Driver Identifier (LDID) The present invention introduces the concept of a language descriptor embedded within objects which may be language dependent. In a preferred embodiment, the descriptor contains sufficient information to convey locale information for an object. Alternatively, particularly for those embodiments having data objects constrained by downward compatibility or storage space considerations, the descriptor is a Language Driver Identifier (LDID) of the present invention. The LDID may be embodied in the form of a system-comparable unit, such as an ID byte which references an agreed-upon set of values (e.g., locale lookup table). For purposes of clarity, the discussion which follows will focus on use of the LDID descriptor embodied as a byte identifier. Those skilled in the art will appreciate that a descriptor or identifier of the present invention may be embodied in other forms, such as a multi-byte identifier, a text string, or even as a variable-length data member (e.g., identifier data record having a record header and body). Regardless of its particular form, however, the descriptor need only be capable of being stored in desired locations to convey information about the language driver that was in use when data objects were created or modified. The LDID of the present invention allows the system to intelligently process data objects created or modified under one language driver with those created or modified by a different language driver. In the event of incompatibilities, the system provides error handling routines, including facilities for warning users of incompatible or otherwise illegal operations. In the simpliest design, there is a one-to-one correspondence between a language driver and its LDID. For example, the language driver for the United States (DB437US) may be identified with an LDID tag of 27. In a more complex embodiment, it may be desirable to include subtypes and/or some redundancy. In a preferred embodiment, LDIDs may be defined for locales (having available language drivers) as shown by the following header file (excerpt):
//
// UNIQUE LANGUAGE DRIVER ID
//
// Paradox
#define pxUS 1 // cp437
#define pxINTL 2 // cp437
#define pxJAPANESE 3 // Shift-JIS
#define pxNORDAN 4 // cp865
#define pxNORDAN4 5 // cp865
#define pxSWEDFIN 6 // cp437
// dBASE
#define dbARABIC 7 //
#define dbDANISH 8 // cp865
#define dbDUTCH 9 // cp437
#define dbDUTCH2 10 // cp850
#define dbFINNISH 11 // cp437
#define dbFINNISH2 12 // cp850
#define dbFRENCH 13 // cp437
#define dbFRENCH2 14 // cp850
#define dbGERMAN 15 // cp437
#define dbGERMAN2 16 // cp850
#define dbITALIAN 17 // cp437
#define dbITALIAN2 18 // cp850
#define dbJAPANESE 19 // Shift-JIS
#define dbSPANISH2 20 // cp850
#define dbSWEDISH 21 // cp437
#define dbSWEDISH2 22 // cp850
#define dbNORWEGIAN 23 // cp865
#define dbSPANISH 24 // cp437
#define dbUK 25 // cp437
#define dbUK2 26 // cp850
#define dbUS 27 // cp437
#define dbFRENCHCAN 28 // cp437
#define dbFRENCHCAN2 29 // cp850
#define dbFRENCHCAN3 30 // cp863
#define dbCZECH 31 // cp852
#define dbCZECH2 32 // cp867
#define dbGREEK 33 // cp437 (Modified)
#define dbHUNGARIAN 34 // cp852
#define dbPOLISH 35 // cp852
#define dbPORTUGUESE 36 // cp860
#define dbPORTUGUESE2 37 // cp850
#define dbRUSSIAN 38 // cp866
// Borland
#define BorlDANISH 39 // Latin-1 (ANSI/Windows)
#define BorlDUTCH 40 // Latin-1 (ANSI/Windows)
#define BorlFINNISH 41 // Latin-1 (ANSI/Windows)
#define BorlFRENCH 42 // Latin-1 (ANSI/Windows)
#define BorlCANADIAN 43 // Latin-1 (ANSI/Windows)
#define BorlGERMAN 44 // Latin-1 (ANSI/Windows)
#define BorlICELANDIC 45 // Latin-1 (ANSI/Windows)
#define BorlITALIAN 46 // Latin-1 (ANSI/Windows)
#define BorlJAPANESE 47 // Latin-1 (ANSI/Windows)
#define BorlNORWEGIAN 48 // Latin-1 (ANSI/Windows)
#define BorlSPANISH 49 // Latin-1 (ANSI/Windows)
#define BorlSPANISH2 50 // Latin-1 (ANSI/Windows)
#define BorlSWEDISH 51 // Latin-1 (ANSI/Windows)
#define BorlUK 52 // Latin-1 (ANSI/Windows)
#define BorlUS 53 // Latin-1 (ANSI/Windows)
#define BorlPORTUGUESE 54 // Latin-1 (ANSI/Windows)
#define dbUS2 55 // cp850
#define BorlINTL 56 // Latin-1 (ANSI/Windows)
// Paradox
#define pxINTL2 57 // cp850
#define pxSPANISH 58 // cp437
#define pxICELAND 59 // cp861
// Paradox WIN
#define pxwINTL 60 // Latin-1 (ANSI/Windows)
#define pxwINTL2 61 // Latin-1 (ANSI/Windows)
#define pxwSPANISH 62 // Latin-1 (ANSI/Windows)
#define pxwSWEDFIN 63 // Latin-1 (ANSI/Windows)
#define pxwNORDAN4 64 // Latin-1 (ANSI/Windows)
// dBASE
#define dbNORWEGIAN2 65 // cp850
#define dbDANISH2 66 // cp850
#define dbICELANDIC 67 // cp861
#define dbICELANDIC2 68 // cp850
#define dbTURKISH 69 // cp853
// ROE 100-120
#define pxCZECH 100
#define pxCZECH2 101
#define pxPOLISH 102
#define pxRUSSIAN 103
#define pxHUNGARIAN 104
#define pxGREEK 105
#define pxGREEK2 106
#define pxHEBREW 107
#define pxARABIC 108
#define pxSLOVENE 109
#define pxTURK 110
#define pxTURK2 111
#define pxTURK3 112
#define pxBULGARIAN 113
#define pxFARSI 114
#define pxROMANIAN 115
#define pxwARABIC 116
#define pxwHEBREW 117
#define pxHEBREW2 118
#define pxwHEBREW2 119
As shown, a locale may be identified with variations, such as Turk, Turk2, and Turk3. Such variations or subtypes may be needed because a given locale may use different code pages or use different sort orders (e.g., dictionary sort versus ASCII sort). There is no requirement that the identifier information be of a particular format. The information may be, for instance, embedded as a text string within a data record or the like. The preferred embodiment of the local LDID in the header section of a data file is illustrated in FIG. 2C. As shown (e.g., for a dBASE .DBF file), the Identifier may be positioned at a known location(s) in the file (e.g., byte offset 29 for the .DBF file). The Identifier, in turn, references a lookup table which identifies the appropriate language driver for the file. 3. Uses of LDID Each installed version of the system 200 includes a preferred or default Identifier (e.g., ID byte), such as may be stored in the above-described resource file (e.g., DBASE1.RES of dBASE). The Identifier, which is referred,to as the "stored Language Driver ID ("stored LDID"), specifies the language driver for which that version of system has been configured. In this manner, it may be distinguished from and compared to corresponding identifiers embedded within data objects themselves. When a session of the system is initiated (i.e., user instructs system to load and begin operation), the stored LDID is read from the resource file. Its value is assigned to the "active Language Driver ID" for that session of the system. The user may override the active Language Driver ID (e.g., by setting LANGTABLES to OFF), whereupon the stored LDID value is overridden with a special value of 27. The active LDID, in turn, is written to data objects which the system "touches" (i.e., creates or modifies). Again using the present example of dBASE DBMS embodiment, the system writes an LDID byte into the following database data objects:
File Type File Extension Location
Data table .DBF 0 .times. 1D
Single index .NDX 0 .times. 0B
Multiple index .MDX 0 .times. 1F in header
(0 .times. 0B in each tag header)
In this fashion, the byte identifier indicates the exact language driver which was employed when the file (or tag) was created or modified. To distinguish it from the "stored Language Driver ID" ("stored LDID"), this locally stored identifier is referred to as the "Local Language Driver ID" or "Local LDID" 215. In a preferred embodiment, the system provides for downward compatibility for systems which may not be language driver aware. In particular, a user-settable command (e.g., dBASE-style SET command) is provided for disabling LDID checking. The default is for SET LDCHECK to be set to ON. To disable the check, SET LDCHECK to be set to OFF. The command may be issued at startup (e.g., in CONFIG.DB of dBASE); alternatively, the command may be specified as an argument to the system (e.g, a dBASE SET command). In a preferred interface of the system, the current state of checking is displayable to the user and managed through use of an internal flag (zero_ldid_msg). Each development group charged with translation may set this flag in the resource file to tell the system whether to show error messages when users load files that have a local LDID which is not set (e.g., is set to zero). When the flag's value is 0, for instance, no message is displayed when a data object (e.g., database file or index file) has a local ID of zero. When the value is 1, however, instances of a local ID of 0 is identified for the user. Operation of the internal flag (zero_ldid_msg) is described in further detail hereinbelow. Whether or not the warning message appears, the local LDID of zero is preferably updated (replaced by the active LDID). Exemplary Uses for Language Configuration The following describes exemplary uses of the tools described in the previous section for managing language configuration tasks. Again for purposes of illustration and not limitation, the description will focus on techniques operative in a database management system embodiment. A. Install: Configure resource file In an exemplary embodiment, application software is "installed" on the system by INSTALL, which itself is a program. In addition to configuring a system towards general preferences of a user, installation may be employed for configuring an application for the user's choice of a default code page. The default language driver for the system may be established by one of several ways. The system may allow the user to select a preferred locale from a list of available drivers, with a default selection provided. Alternatively, the country configuration of the current operating system may be determined (e.g., from looking at the active code page, or from calling MS-DOS Get/set country information services), with a language driver. appropriate for the country being automatically selected. If an appropriate driver is not available, the user is warned. B. Checking for Correct Code Page 1. Reconciling Application and OS Code Pages It is possible, on occasion, that upon execution of an application, the code page for the application (as specified in the application's resource file) does not correspond to the code page for the operating system. Thus, in a preferred embodiment, it is desirable to detect such instances and notify the user (e.g., with the error message, "System is not configured for current code page"). It is also desirable to detect instances where users have switched to an alternate code page for their country. If a user in the United States has, for example, switched to code page 850, the situation should be detected and (optionally) reported. When the active code page does not match that of the application, therefore, a user may be given the option of changing the code page of the OS to match that of the application or, alternatively, change the code page of the application (e.g., through an "install" or "config" utility) to match that of the active OS code page. 2. Loading Application and Active LDID When an application is loaded (from mass storage into the system memory for execution by the processor), the application first checks the LANGTABLES setting, if LANGTABLES is off, the application sets the active LDID to the default value (e.g., a value of 27). Otherwise, the program sets the active LDID for the current session to the value of the stored LDID in the resource file. Employing the above-described zero_ldid_msg flag, the application when loaded may also check a status flag (byte) in the resource file for determining whether to suppress error messages when a user opens files with a local LDID of zero. C. Example: Opening Database Files The following example will illustrate application of the principles of the present invention for the operation of opening a file, such as a database file. Referring now to FIGS. 3A-B, a preferred method 300 of the present invention for processing a request to open a file in a system having National Language Support includes the following steps. At step 301, a request is received by the system for opening a file. For example, in the instance of a database application, an open or use (e.g., dBASE USE) command may be issued for opening an existing database file. As is known in the art, a request to open or otherwise obtain a handle to a disk file is typically done in conjunction with a particular access mode, that is, a file can be opened in different ways. For instance, a file may be opened for "read-only" access. In the instance where one needs to both read to and write from a file, a "read/write" access mode or type is appropriate. As still yet another type of access, one may need to only append information to an existing file (i.e., write new information to the terminal portion of that file); "append" access may be treated as if the existing data is read-only. Access mode is important as it determines the ability of the system to touch (create/modify) the data object. After receiving a request to open a file in step 301, the method proceeds to step 302 to determine whether language-driver checking is enabled. If language-driver checking has not been enabled (no at step 302), then the method proceeds to step 306 to open the data file in a normal fashion (i.e., without further checking), using the specified access mode. If, on the other hand, checking has been enabled (yes at step 302), then at step 303 the language driver identifier (LDID) in the data file is read. In a preferred embodiment, the identifier will be stored in the data file at a position where it may be conveniently accessed upon first reading the file. The identifier may be stored, for instance, within a header of the data file. Those skilled in the art will appreciate, however, that the identifier may be positioned at a different location or locations within the data file. In the instance of a data file comprising a plurality of data regions (either logically or physically discrete), the language driver identifier may be stored within any organizable unit of data where language configuration is important, including within selected records or fields (individually or by group) and the like. Alternatively, the identifier may be stored in a footer to the file but in such a case should preferably be read before processing other information contained within that file is undertaken. At step 304, an optional step is added to maintain backwards compatibility (such as for data files created by systems (typically, older ones) which do not know about language driver information. If meaningful information is not stored by the LDID (e.g., LDID=NULL), then the method proceeds to step 305 for special processing of what is determined to be an non-language aware (older) data object. At step 305, one of four paths may be pursued. In the case that the warning ("no driver") message has been disabled (zero_ldid_msg=0), and the specified access mode is read-only, then the method proceeds to step 311 to suppress any warning message, complete the file open operation as read-only access, and leave the local LDID (i.e., the ones stored in the data file) as zero. In the case of the message being suppressed and the specified access mode is read/write, the method proceeds to step 312 to suppress any warning message, continue to open the file with read/write access, and set the local LDID to the value of the active LDID (thus updating the file for language configuration). The remaining two case arms of step 305 proceed as follows. In the case of the warning message being enabled (zero_ldid_msg=1) and read-only access, the method proceeds to step 313 to display a warning message for the data file. As shown by FIG. 4A, for example, a dialog box 410 may be displayed on the screen device for conveying this information and asking the user whether to proceed with viewing (i.e., read-only access) the file employing the current language driver (i.e., the one specified by the active LDID). Thus as shown by the dialog box 410, the user may elect to proceed at this point or cancel the operation (whereupon the file is not opened). If, on the other hand, the warning message is enabled (zero_ldid_msg=1) and the specified access mode is read/write, then the method proceeds to step 314 to display a warning message, such as shown by dialog box 420 of FIG. 4B. As shown, the user is informed that no language driver has been specified for the data file. The user is queried whether he or she wishes to open the file (with read/write access) and assign the current language driver to it (i.e., update the local LDID in the file to the active LDID). These operations may be summarized by the following table:
zero_ldid_msg Mode Action
0 R/O Do NOT show the R/O no
driver message; open file R/O;
leave local LDID in .DBF as
zero
0 R/W do NOT show the R/W no driver
message; open file R/W; set
local LDID in .DBF to match
active LDID
1 R/O show the R/O no driver
message; if file is used,
leave local LDID in .DBF as
zero
1 R/W show the R/W, no driver
message; if file is used, set
local LDID in .DBF from active
LDID
If the LDID identifier is set to a valid value, at step 304, then the method proceeds to step 321. As shown in FIG. 3B, at step 321 the method compares the LDID of the data file (local LDID) to the current or active LDID. If the two are identical or compatible at step 322, then the method may proceed to step 323 to open the file per the specified mode; thus at this step, the method has determined that the system can process the language-dependent data file without error. If, on the other hand, the LDIDs are incompatible (no at step 322), then the method branches to step 324 to handle the exception. At step 324, for instance, the system may automatically translate the data file into a format which is compatible with that currently employed by the system; alternatively, the system may be automatically set to a language driver which is appropriate (compatible) for the data file. If desired, the user may assume some responsibility for the process. As shown by dialog box 430 of FIG. 4C, for example, the user may manually instruct the system to abort or cancel the operation. The user is also given the option to change the existing setup (e.g., setting the system language driver to one which is compatible with that of the data file). Finally, the user may instruct the system to proceed, typically having changed the setup to compatible drivers, or even leaving the drivers as incompatible (e.g., in the instance where the user knows beforehand that the information to be processed within the data file is itself not language dependent). If the system is to proceed (either automatically or manually), then at step 325 the method branches to step 323 to open the file per the specified mode. Otherwise (no at step 325), the method concludes without completing the file open operation. In the instance of a multi-national organization with distributed database files, it is desirable to ensure that the LDID replacing the zero-stored LDID is the one most useful to the organization as a whole. For example, if the company does ninety percent of its business in France, Germany, and Italy, it would be awkward if the first user of an important pre-existing file (i.e., one having LDID=0) were a sales representative from Poland. Specifically, if the zero-stored LDID is replaced by the Polish LDID, then subsequent multi-national users who attempt to open that file will receive a warning that the language drivers do not match; only Polish users would not get this warning. Moreover, it would be awkward if this same organization let the first user of the file be someone with language drivers disabled (i.e., LANGTABLES set to OFF), if most of the users of the organization have enabled language drivers (LANGTABLES set to ON). In such an instance, most users would see a mismatched message. One approach to the problem is to select the best common denominator--a code page (such as 850) that contains most of the accented characters needed. Each language driver includes not only a code page but also the above-mentioned country-specific tables. Whether a French 850 or an Italian 850 language driver is more appropriate for its data processing needs as a whole would be for the company to decide. The action which the system undertakes when the local LDID has been previously set (i.e., is not equal to Zero) may be summarized by the following table: When Local LDID is not Zero
Active LDID
Matches Stored
LDID? Action
YES open file with no message
NO show mismatch message
if file is used, do not
change; local LDID in
.DBF
D. Example: Interrelated Files Referring now to FIGS. 5A-D, application of the principles of the present invention to the management of language configuration for interrelated files will now be described. Often in the use of information or data files, one file will be dependent upon information stored in another. As shown in FIG. 5A, for example, an index file 270 (e.g., dBASE .MDX or .NDX file) must be compatible with its target table file 260 (e.g., dBASE .DBF file). The problem is compounded by additional interrelated data objects, such as a report object 280 for the table 260. Consider the following problem. When an index file is created under one language driver and then employed under another, for instance, the order of the data in the table as specified by the index file may be erroneous (since the collation tables of the two differ). Other features of the system which depend upon a correct relationship between the two files may also be corrupted. If a user attempts, for instance, to view information in the table with a particular filter condition in place (e.g., SET FILTER TO LASTNAME="SMITH"), the result obtained may not be as expected. Other language-dependent operations (e.g., convert to uppercase, convert to lowercase, Soundex, is alphanumeric character, and the like) may give unexpected results under the active language driver. Finally, under such circumstances the system may not be able to correctly update the index when a record is modified or added to the table, especially in those instances where the index key expression contains special characters. Thus, it is desirable to identify such instances so that they may be correctly handled. A general approach for dealing with such an instance is as follows. The mismatch between the interdependent files is identified by comparing the LDIDs for each. For instance, database table 260 may store a first Local LDID 265, index file 270 may store a second Local LDID 275, report file 280 may store a third Local LDID 285, and so forth. Before a dependent file is employed, its LDID is checked against that of the data object for which the dependent file is employed. In this manner, incompatibilities between interrelated files may be trapped and processed accordingly. For many dependent files, such as the index file, the file may be regenerated or rebuilt from a master file (e.g., by rebuilding the index file from the table according to the indexing criteria); thus, the dependent (index) file may be automatically converted into a file which employs a compatible language driver. Alternatively, the system may display manual options for the user to reindex the file, cancel the operation, or the like. FIG. 5B illustrates the use of separate regions for storing different language-dependent information within a single file. In particular, system 285 includes a multi-region data object 290. As before, the data object includes a header region 291 and a data region 293, with the former storing (optionally) a local LDID 292. The data region 293, in turn, includes multiple logical files or data regions 294, 296, 298, each of which may store language-dependent information. The first data region 294, for instance, may store information created or modified using an English language driver; hence, its local LDID 295 stores an identifier for that particular driver. Similarly, the other regions 296, 298 may store language-dependent information created with other language drivers. Region 296 may store information in French, with its local LDID 297 storeing a reference to the French language driver. Region 298, on the other hand, may store German information, with its local LDID 299 storing a reference to the German language driver. Each region is arranged (e.g., with record tags) so that it may be accessed as a logically separate object. In this manner, the system 100 may select one or more data regions from the object 290 for use with the active language driver of the system (as selected from drivers 240 with the active LDID 230). Moreover, a single file may store multiple copies of the same information, with each copy storing the information under a particular language driver. In FIG. 5C, the concurrent use of multiple active language drivers is illustrated. System 350 operates simultaneously on data objects created or modified with different language drivers. For instance, a first data object 360 may be a set of programming instructions (e.g., dBASE .PRG file) which were created under a first language driver (e.g., English). The data object 360 may direct the system 100 to perform some operation on the other data objects. The data object 360 may include, for example, the command to index a table (data object 365) to a particular index file (data object 368). Although the instructions (from object 360) are in a particular language, English in this example, there is no need for the targets of these instructions to also be compatible with that language. Instead, the system 100 need only "understand" (i.e., apply the correct driver to) the data object 360 so that it may carry out the desired operations on data objects 365, 368. This is achieved as follows. The data object 360 stores a local LDID 361 which is matched to a first active LDID 230a. Data objects 365, 368 (which stored their respective local LDIDs 366, 369) are matched with a second LDID 230b. In this fashion, the system 100 may correctly "talk to" (i.e., process) each data object with its appropriate language driver (selected from drivers 240 with the respective active LDID). Although the system 350 illustrates the simultaneous use of a pair of active LDIDs, those skilled in the art will appreciate that multiple active LDIDs may be employed in the fashion just described to achieve concurrent processing for a multitude of language-dependent data object, each of which may have been created or modified with a different language driver. Referring now to FIG. SD, a method of the present invention for processing language-dependent interrelated files will now be described. The method 500, which emphasizes operation of system 250, includes the following steps. At step 501, the system receives a request to "open" the dependent file, such as when a user accesses a database file having an associated index file. At step 502, the system determines whether language-driver checking is enabled (e.g., LDCHECK is ON). If checking has been disabled (no at step 502), then the index file is opened without further checking at step 506, and the method concludes. Otherwise (yes at step 502), the method checks the value of the local LDID stored in the index file (e.g., such as stored in the header of an .MDX or .NDX file). At step 504, if the index file is not language-driver aware (LDID=0), then the method proceeds to step 505 for providing backwards compatibility (for indexes created under older systems). At step 505, for the case of LDID message being disabled (zero_ldid_msg=0), the method proceeds to step 511 to open and use the index file but without a warning ("no driver") message being displayed. Upon the first update (write operation) to the index file, the local LDID is updated to the active LDID. An index file may be written to, for instance, when its key expression is modified, a tag's key expression is modified (in the instance of a multi-tagged index file, such as dBASE.MDX), a new tag is created, a tag is deleted, or the user issues a command to "reindex" the table. In the instance of a multi-tagged index file, the value of the active LDID also replaces the zero value of the LDID in each tag header. If, on the other hand, the zero_ldid_msg flag is enabled (indicating that warning messages are desired), then the method proceeds to step 513. At step 513, the system issues a warning to the user that the index file about to be opened does not have an assigned language driver. As shown in FIG. 6A, for example, a dialog box 610 may be displayed with this information. As is also shown, the user is offered options on how the system should proceed. If the user chooses "cancel", the index file is not opened; actual processing of the corresponding table file (without applying the index) may continue if desired. As a second alternative, the user may select a "reindex" option, in which case the index file is reindexed (rebuilt); at this point, the value of the active LDID is written to the local LDID in the index file's header. The value of the active LDID is written to the header of each index tag. In the instance of a multi-index file (.MDX), all the indexes in the file are updated with the active language driver. Any tag header which includes a zero value for the LDID is updated with the value of the active LDID. As a third alternative, the user may instruct the system to use the existing index file. In a preferred method of the present invention, the index file is not reindexed, but nevertheless the value of the active LDID is still written to the local LDID header and tags (as described above). This third option provides flexibility for those users who know that the existing indexes are acceptable and do not wish for the system to take time to regenerate them. The easiest approach is of course to always choose "reindex". The behavior for local LDID values of zero is summarized in the following table: When Local Index LDID is Zero
zero_ldid_msg Action
0 Do not show "no language driver"
message; set local LDID in .MDX or .NDX
header to match active LDID; set all
local LDIDs in tag headers to match
active LDID
1 Show "no language driver" message; if
file used, set local LDID in .MDX or
.NDX header to match active LDID, also
set all local LDIDs in tagheaders to
match active LDID
If the local LDID is not zero at step 504, then the index file has already been modified by a language-driver aware system. In such a case, the system may compare the local LDID with the active LDID in a manner similar to that set forth in FIG. 3B (steps 321-325 of the method 300). The local LDID and the active LDID are compared (step 321). If the two match (step 322), then the current session of the system is running with the same language driver which was used to create or modify the index file. In such a case, the index file is simply opened and-employed with its corresponding database table file at step 323. If, on the other hand, the non-zero local LDID is not equal to the active LDID, then an LDID mismatch results (no match at step 322). An LDID mismatch results when the language driver originally used to process the index file differs from the language driver in the current session of the system. Because this mismatch can cause several problems (described above) it is trapped by the system (step 324). In a preferred embodiment, a language driver incompatibility dialog box 620 is displayed to the user for indicating the incompatibility. As shown in FIG. 6B, the user may instruct the system in how to proceed. If the user chooses "cancel", then the index file is not opened and the operation terminates (or optionally continues without an index) as described above for step 513. If, on the other hand, the user selects the "reindex" option, the index file is regenerated, with the value of the active LDID written to the local LDID in the index file's header. Again (as described above for step 513), the value of the active LDID is written to the header of each index tag. In the instance of a multiple index file, all of the indexes in the file are updated with the active language driver identifier. The behavior for local LDID values which are not zero may be summarized by the following table: When Local Index LDID is not Zero
Active Index LDID
Matches Stored
LDID? Action
YES open file with no message
NO show index mismatch message;
if file reindexed, set local
LDID in .MDX or .NDX header to
match active LDID, also set
all local LDIDs in tag headers
to match active LDID
While the invention is described in some detail with specific reference to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. For instance, while the preferred embodiment employs a byte-length identifier, a variety data types may serve in the manner of a descriptor of the present invention, including use of a self-contained locale descriptor (i.e., embedding necessary locale information within the data object). For those embodiments constrained by compatibility or storage space, the descriptor may be embodied in the form of a system-comparable unit, such as an ID byte which references an agreed-upon set of values (e.g., locale lookup table). Thus, the true scope of the present invention is not limited to any one of the foregoing exemplary embodiments but is instead defined by the following claims.
|
Same subclass Same class Consider this |
||||||||||