The DataView Reader registry keys are logically split into the following categories: metaknowledge location, string encoding, string handling, and navigation handling.

Metaknowledge Location

The DataView Reader task is to expose data views defined in Inspector. The knowledge about these data views is called metaknowledge, and can be stored by Inspector in different locations, according to its settings.

The key "Where to save" (REG_DWORD) can contain the following values:

• Metaknowledge is saved in the file system; in this case, the key "database GPH" (REG_SZ) contains the full path of the directory where the metaknowledge is stored (it must terminate with a / character). Inspector by default sets "Where to save" to 1 and "database GPH" to "inspector-rootdir\db_gph\".
  
• Metaknowledge is saved in the database to which the metaknowledge is referred. This is the recommended choice if you want to deploy an application that uses the DataView Reader to expose the contents of your database.
  
• Metaknowledge is saved in an ObjectStore database dedicated to storing it; in this case the "ObjectStore database" (REG_SZ) key contains the full file name path of the ObjectStore database.
  

Character strings can be encoded in a wide variety of formats inside a database. Inspector and the DataView Reader let you specify the default encoding type of the character strings stored in your databases (this default can be overridden on a per-class basis in each database, using Inspector). The DataView Reader always returns strings in ASCII or SJIS encoding type.

The default character string encoding is stored in the "AttributeFormatDisplayingDefault" (REG_DWORD) key. The possible values are

• 1: Character strings are simple ASCII, and they do not use any particular encoding (default).
  
• 2: Character strings are encoded in SJIS (Windows-Japanese) format.
  
• 4: Character strings are encoded in EUC (UNIX-Japanese) format.
  
• 8: Encoding type of character strings must be recognized automatically by Inspector or DataView Reader.
  
• 16: Character strings are encoded in Unicode format.
  
• 32: Character strings are encoded in UTF8 (Java-Unicode) format.
  

The "UseJapaneseRegex" (REG_DWORD) registry key contains information on whether the DataView Reader must invoke the Japanese-compliant version of the regular expression parser used in the queries:

• 0: (Default) Use the standard regular expression parser.
  
• 1: Use the Japanese-compliant regular expression parser.
  

Strings can be stored in buffers of characters in many different ways. Inspector and the DataView Reader let you specify the default way in which strings stored inside your databases should be retrieved (this default can be overridden on a per-class basis in each database, using Inspector).

The default setting is stored in the "AttributeFormatInterpretationDefault" (REG_DWORD) key. The possible values are

• 32: Show the string until the first NULL character in the buffer is met (default).
  
• 64: Show all the characters in the allocated buffer, skipping the invalid ones.
  
• 128: Show all the characters in the allocated buffer, and use a special character to replace the invalid ones. This special character is stored in the "AttributeFormatSubstitutionDefault" (REG_SZ) registry key.
  

In all the preceding cases, if the resulting string is longer than the Blob Size, the string is not displayed, and the "XXX bytes at address 0x123456" message is returned. The Blob Size is stored in the "MaxNonBinaryBlobSize" (REG_DWORD) registry key (the default is 768).

• 256: Like 32, but truncate the string at the Blob Size if needed.
  

The "SingleCharacterFormat" (REG_DWORD) key contains information about how to report single-character data members:

• 0: (Default) Single character is returned in the format `A' (65).
  
• 1: Only the single character is returned: A
  

When a data view uses a data member that represents a one-to-many or many-to-many relationship, Inspector and the DataView Reader can choose between two possible algorithms. Information about which algorithm should be used is stored in the "OLEDB SQL-like join" (REG_DWORD) registry key:

• 1: (Default) Use an SQL-like approach. The DataView Reader expands one-to-many relations to show all the possible values that meet the conditions of the query (as an SQL join would). Consider a data view that lists the names of customers together with the makes and the models of the cars they own. With this approach, the output takes this form:
  
  

  Name	Make	Model
  John, Smith	Cadillac	Deville
  John, Smith	Ford	Escort
  Jones, Mary	Ford	Ranger
  Jones, Mary	Mazda	626
  Jones, Mary	Mazda	626

  
  
• 2: Use a tree-like approach. With this approach, the data view above takes this form:
  
  

  Name	Make	Model
  John, Smith	Cadillac	Deville
  	Ford	Escort
  Jones, Mary	Ford	Ranger
  	Mazda	626
  	Mazda	626

  
  

Usually a tree-like view is more readable, but an SQL-oriented tool such as a report generator cannot easily use it. In the SQL-like view, if you navigate multiple one-to-many relations in a row, the number of generated rows is much greater than in the tree-like view.

This class is used by both the client and the Server. It defines the functions the client uses to set the router and to connect to and disconnect from a Component Server. It also defines an enumeration relating to the fundamental types of data Servers and thin clients can exchange, as well as an enumeration relating to transaction types.