The second step is likely the most time-consuming, but also the most important: telling Stonefield Query about the data it queries on. Unlike other reporting and querying tools that have no specific knowledge of a particular database, Stonefield has detailed knowledge about the databases it queries against. That's the key to Stonefield Query's ease of use: the users don't have to know what a join is, let alone how to create a join for a particular set of tables, nor do they have to know the names of tables and fields.

What gives Stonefield Query this knowledge about the databases is its data dictionary. The data dictionary has information about the databases themselves (where they are located and how to access them) and their tables (their names and descriptive headings), fields (names, headings, data types, formats, and so forth), and relationships (the expressions used to join pairs of tables).

Filling in the Stonefield Query data dictionary for a database would be a very tedious process if you had to do it by hand. Fortunately, the Configuration Utility has a feature to "discover" the meta data for a database. You do this by adding a database to the current project's data dictionary. This creates the meta data (information about the data structures) for the database and all of its tables, fields, and relationships. See the Adding a Database to the Data Dictionary topic for details on the discovery process.

Once the Configuration Utility has created the meta data for the database, the next task is to fill out the properties of each object in more detail. Which properties you specify depends on the type of data object:

• Database: there aren't any properties to specify for a database. Instead, you may need to create some scripts for things such as which data source to use for a database.

• Table: the only property you need fill in for a table is the caption, the descriptive heading the user sees rather than the real table name. There are other properties available as well, including Reportable, Data Group, and User Groups. See the Table Properties topic for a complete list.

• Field: at a minimum, fill in the Caption for each field. Other properties, such as Format, Picture, Reportable, Sortable, Filterable, and Output Expression, can be changed as necessary. See the Field Properties topic for a complete list of the properties for a field.

• Relation: you need to define a relation for each pair of tables, specifying the tables, the fields to join them on (or the join expression if it's more complex than a pair of fields), and the join type. See the Relation Properties topic for more information.
  

You may also wish to define some calculated fields. A calculated field doesn't physically exist in the database, but is simply a formula that gives a value the user may want to query on. An example is the extended price of a sale item. This usually isn't stored because it's a derived value (price per item multiplied by the quantity sold), but the user may want it printed in a report or use it in a filter condition. So, you can define a calculated field in the appropriate table, specifying the caption, data type, and output expression (the formula) for the field. This field is then available for querying just like a real field -- the user can include it in a report or filter on it -- but internally, Stonefield Query uses the formula to derive the value.