The Reply Style Option allows you to select the manner in which you'd like Access ELF to respond.

Datasheet is the quickest, most compact response.

You might prefer to view the answer to your query row by row. You can do this by selecting the Autoform option. Autoform uses the built-in Access Form Wizard to produce a simple tabular form that displays a single record at a time.

If you select the Custom reply style, the Form Style buttons become active. This allows you the same degree of flexibility in designing your forms that the Form Wizard permits. Note that for these options to work properly, the Access Wizards must be available as libraries. If the Wizards are not installed (or become uninstalled), you'll need to rerun the Microsoft Access installation, choosing Advanced Wizards to recover this capability.

You can also select the "Transparent Fields" option, which greys out text fields unless the cursor is moved into that field; whereupon the field background becomes white.

The Graph Reply style lets you can request a graph without working it into the wording of your question. Instead of asking "Graph the number of customers from each country." you can simply click Graph, and ask "How many customers are there in each country?"

The automatic graphs will resize themselves as their windows are resized, and can be sorted or limited to the "top N" by using controls on the form footer. You can also enter your own filter, referring to the graph label as "L" or the graph value as "V". Two examples are given, one restricting the labels to those starting with alphabetic characters (L >= "A" and L <= "Z"), and one enforcing positive graph values (V > 0). The first is actually written: L Like "[A-Z]*", which demonstrates how you can use patterns for filters. If you want to eliminates all but labels which start with the letters A-C, you can type: L Like "[!A-C]*"

There are currently three distinct styles of graph supported, Pinnacle, Microsoft Graph 5, and Microsoft Graph 6. Each behaves in a different way, and has different strengths and weaknesses. All three styles allow you to display the graph full-screen. For Pinnacle and Graph 6, click the lower-left X to hide the controls, then maximize the window. For Graph 5, right-click the graph and maximize.

The user-defined form style lets you use nearly any Microsoft Access form as a display vehicle for your query. Of course, the query should have something to do with the fields displayed by the form. But the fields don't need to be individually named or otherwise selected. Access ELF will take care of all the details of reading the source fields for the controls on your form (and that includes calculated controls). It will create a query which uses the conditions you specify in the question, plus all the fields required by the form, and package them into one neat SQL statement (as usual, possibly relying on earlier SQL statements which it will also create).

Other options on the Responses Tab of the Settings window include the BestFit Columns check box, and the MakeTable selectors. The BestFit check box determines whether Access ELF will resize the grid columns on the datasheet (and Worksheet data grid) responses. If set On, ELF will try to scale the column widths to its best guess of the length of the longest data (and/or the column header). This is not fool-proof; it's based on the first 20 or so records returned by the query.

The MakeTable option allows you to specify the name of a table which will be generated to hold the answer to your question. By default, responses are returned as queries, which are temporary objects. If you want to save this off as a permanent copy, you can use the MakeTable feature. This would have the same effect (although it's somewhat easier) as switching the response query into design view, and walking through the Make Table dialog.

The Views tab shows all of the interfaces (Views) currently defined for the active database. You can load a View by clicking on its name in the Available Views listing.

You can create more than one view for any database. In fact, it's highly recommended that you pick a small subset of tables for each view. Think of it like this: you wouldn't try to represent your entire business in a single spreadsheet; same goes for natural language views. Break down your database into logical sections and create a view for each one.

You can run any number of Analyses, using a different set of tables, queries and startup options, giving each one a unique name. These can be as specific as you like; for instance, only using information from a small set of tables.

The Verb Mapper allows you to associate an action word with the relationship between two tables (or between a table and an Analyzed query). For example, we can associate the verb "handle" with the link between Employees and Orders. It's as easy as typing the word handle into the box between the two tables, so that it reads across "Employees handle (s) Orders". If the relationship should read in the other direction, use the Flip button to invert. You can, if it makes sense, define separate verbs for the relationship in each direction.

The relationships don't have to be direct table-to-table (or table-to-query). You can define relationships between datasets that have indirect relationships. To add a new Verb Mapping, click the New Record indicator (arrow star) on navigation control, or just keep advancing to the next record until the "Define A Relationship to Associate with a Verb" dialog box appears. You can then select a table from Column A and one from Column B, for instance Customers and Products. Rather than displaying the keys, as it does for direct joins, the join boxes will display the tables used to link the two data sets; in this case Orders and Order Details. Now we can define the following: Customers enjoy(s) Products and (after clicking the "Flip" button) Products satisfy(s) Customers.

After making these definitions, Access ELF will understand questions such as "Who enjoys Gumbo Mix?" and "What satisfies Handel?" (you guessed it: Gumbo Mix!)

You can display hierarchies in the Worksheet by using the Verb Mapper to let ELF know about hierarchical relationships -- such as organizational structure (who bosses who) or parts-dependencies. To do this, add an entry to the Verb Mapper by using the Add New record button (arrow and star). Choose the same table on both sides of the relationship. Click a field on the left, for instance [Employee ID], and a field on the right, for instance, [Reports To]. Now you can use the Hierarchy buttons in the worksheet to get a tree display. Or use "as a hierarchy" in your question, to display records in hierarchical order.

Tip: Be careful when using this function to click on actual key values, not -- by accident -- other numeric fields. This instructs ELF to ignore these fields when creating graphs; and deleting the reference later won't restore "graphability."

Another use for the Verb Mapper is for linking fields which you want to display togather. Let's say that every time you display the "Document" field, you want to also display "Case ID". Add a Verb Map entry using the verb "IMPLY". The two fields can come from the same, or from different tables. Now, whenever you see Document in the response, Case ID will be there too.

(Note: if the two tables are related, Access ELF will fill in the relationship in the place where you want to select the fields to relate. To override, just type in the verb IMPLY, then double-click one of the fields pre-selected by the program. This will unlock the list of fields in each table so that you can click one on each side.)

You can also use this feature to relate two fields using the special verb "drill". This defines a drill-down relationship; which means if you double-click in the Worksheet on a data item from one field, Access ELF will run a query showing related values from the other field. Typical would be to relate COUNTRY to STATE by "drill' so that double-clicking on "USA" would break down the displayed values state-by-state.

The next-to-last tab is where we've placed some of the less common customizations, as well as administrative functions such as import/export of Views and lexicon maintenance.

The Import/ Export ELF Interface buttons should make swapping interfaces a breeze. You can copy a .ELF folder to a network drive or floppy disk in just a few clicks. From there it can be zipped and emailed (or just hand-delivered) and your friends or customers can import the unzipped folder into their own Access ELF installation.

There are no licensing changes, redistribution charges or royalty charges for distributing Access ELF interfaces. Once you've created a natural language query system for your Access database or application, it can be used without charge by anyone you wish. To use your interface, users simply download the free Access ELF program (v4.0 or above) . They don't need to purchase a license, because the license is transmitted along with the interface (.ELF folder) you provide them with. This license includes the ability to use each and every feature of the software -- except the ability to create new interfaces for their own databases. (They can still adapt the interfaces shipped with your application using any of the customization features.)

Check Lexicon Size allows you to measure how full the lexicon has become. The lexicon is a disk file which uses a "hash" technique to ensure quick access. It should always have at least 50% free space to provide best performance. Access ELF usually does a good job of estimating the amount of hash space required for a given database, but in some cases it may miscalculate. This button lets you verify that the free space it within acceptable limits. If more space is required, you'll need to rerun the Analysis, manually overriding the AutoSelected dictionary size (increasing the value).

The Synchronize Lexicon button scans through your database, checking for any vocabulary that's been added since the last analysis performed. If you've added a new record for "Bob Smith", Access ELF needs to know, so that it can handle questions like "What's Bob Smith's phone number?" Of course, if your database is small enough, running a complete analysis from scratch is no problem, especially if you've saved any configuration choices with the Save button on the Custom Analysis window. But with larger databases, you may be able to save some time by just re-synching the one or two most volatile tables, instead of re-analyzing the whole database.

The MDB, Table and Field buttons on the Table/Field Source window launched by the Synchronize button offer three different "bite-sizes" for re-synching ELF's lexicon with your current database contents. Note that you can also use this sync feature to "un-exclude" a given field's data from the lexicon. That is, if the Mem (Memorization of vocabulary) box was checked off during a Custom Analysis, but you've changed your mind and now want to include all the text from this field, use Field Synchronization and answer Yes during the override dialog.

The Delete Analysis Tablebutton removes the elfAnalysis table associated with the current View. This table is created at the time that a custom analysis is performed with the Save Analysis checkbox marked. The table is used to store the individual decisions made by the automatic inetrface generator for later inspection (and/or customization) with the Analysis Editor. (The location of the table is the Custom.mdb file stored into the .ELF folder of the created View. ) Once this table has been generated, launching an analysis causes a prompt message to inquire whether the stored (and possibly modified) decisions should be incorporated into the current analysis. If no hand-modifications have been made, this table may no longer have any purpose, so the Delete Analysis button provides a one-click method of removing it from the View.

The ShowWarnings checkbox determines whether warning message boxes will be active or suppressed. Warning boxes come from two different sources. They can be generated by the program when the Permit Rewordings and Warn on Rewordings options are set. This will inform the user that the question may or may not not have been fully understood -- a "backup" system for handling partially-undertood questions was used Otherwise, the only warning messages will come from scripts that you write. You can trigger warning messages to appear by setting the WarningCode variable to a non-zero value and the WarningString variable to your message.

The Debug Break checkbox will be mostly of interest to developers who like to open the hood and look inside at the software engine. With the Break box checked, Access ELF will open a window into the running library code (elf32.mda) whenever a question is sent. This allows you to trace into the code to examine its inner workings. Breaking into running code can also be accomplished with the <Alt-F11> key combination.

Access ELF uses a statistical sampling method during the analysis process, while trying to answer various questions about the relationship of fields with one another. While this method is usually fairly accurate, it's possible that some cases might require looking at the entire table. With version 4.0, we've added this option to allow administrators to force the analysis to examine each row of each table when deciding these questions.

Note that for large databases, turning off the Use Statistical Sampling option will markedly increase the running time of an analysis.

Max translation time lets administrators of Access ELF installations set a predetermined time-out for query processing. Normally, when Access ELF is going to understand a question, it does so relatively quickly. What's frustrating is that it can take an unreasonable amount of time to fail. A good compromise is to set some time limit -- for instance 30 seconds -- automatically cancelling queries that don't yield an answer in that time.

Setting this value to 0 allows the translation to runs its full course without interruption.

The Query Prefix applies to temporary queries that Access ELF writes when answering your questions. You can change this prefix to one of our own choosing. (Since these queries appear in the user's database container, you may prefer query names that remind the end-user of your company, not ours.) On networked databases, which can be opened by more than one user at a time, Access ELF will detect multiple users and add a unique 1-character tag after the query prefix for each user. For instance, the second user on the system might see his queries as elfQX1, elfQX2 etc. If you're on a single-user system and are getting these extra characters, clean out the elfQuerySession table in ELF32.MDA. (This table should clean out inactive entries about every 12 hours, automatically.)

Because it's annoying to get that "Sorry, unable to interpret the question." message box, many users requested that they be able to tailor the message to suit their application. Now it's just a matter of entering the Default "Sorry" message on the Advanced Tab.

Remember that can also define specific error messsages to show in response to particular words or phrases in the question. Do this by preceding a lexical phrase definition with an exclamation point. For instance, you can pop-up a message that says "We don't allow profanity here" if the user types in a word on your list of undesirables. The header for the column in which this message will appear can be defined in the phrase definition itself (following a semi-colon).
When I Type: !hell     I Really Mean: We don't allow profanity here;Stern Rebuke to User

If you don't specify a header within the error text, then whatever appears in the Default Custom Error message header" textbox will be used. And if no message is supplied, the header will read "We regret to say:" (We're sure you can do better than that!)

The final tab (not shown) is where scripts used by all of Access ELF's scripted components must be saved. (Sorry, we're still using old screenshots!) You can also use the script window to edit you scripts in-place, although this is somewhat clumsy. Slightly better is using the Zoom box (Shift-F2) to give yourself more working room for script editing. We generally prefer to tinker with scripts in a text editor such as Notepad, then cut-and-paste into the Scripts panels when ready to use (or test) them.

There are 5 types of scripts that can be used in Access ELF. To summarize, there are:
Analysis scripts which automate any post-analysis customizations required.
Question scripts which intercept the input (or question) from the user.
Answer scripts which intercept the SQL generated by the interface.
Phrase scripts which intercept the question ONLY IF the specified phrase is contained in the input.
Spellcheck scripts which are triggered when one or more words in the input are unrecognized.

In each case, the script must be placed in the Script repository prior to being registered with Access ELF. If the script does not already appear in the repository under the name you are trying to use to register it, a warning message will trigger when you click the activation checkbox.

Except for Phrase scripts, all scripts are registered by typing their name into the scriptname box, then checking the script option checkbox.
Spellcheck scripts are registered on the Preferences tab.
Analysis, Question and Answer scripts are registered on the Views tab.
Phrase scripts are registered by typing their name into the ScriptName column of the associated phrase in the Phrases window

The ScriptName is both the identifier of the script panel entry (for example, when #INCLUDEing one script panel into another) and the name of the function within that script which will be called when the script is triggered. For this reason, most script panels will contain a function which has the same name as the script itself. An exception to this might be a script panel which contains utility functions that are included in one or more other scripts. In that case, since the script won't be referenced directly (and isn't registered in any of the four ways described above), it would have no need of a "namesake function".