1) AnswerScripts have been modified to permit their return value to consist not only of a modified SQL expression, but also the name of a pre-existing query within the database. In addition, a global property QueryParms has been added; this allows you to return the name of a parameterized query as the function result of an AnswerScript, while providing any required parameter values in the QueryParms property.

The QueryParms property uses a simple convention: it is a set of paired "ParameterName;Value;" entries. For example, an AnswerScript might return the string "PetFriendlyHotels" which is the name of the following parameterized query:

Prior to returning this value ("PetFriendlyHotels"), the script would be obligated to set the appropriate parameters for the query; for example:
QueryParms = "CityParm;Denver;StateParm;CO"

Access ELF will never set the QueryParms property by itself. It only uses this property to transfer parameters specified within a script into the SQL statement which is the final result of a query. It is also possible to use QueryParms directly with the SQL returned by an AnswerScript; without having a pre-existing query in the database. This might be simpler in some cases than creating the complete SQL statement, since SQL created within scripts might also benefit from the modularity of having replaceable parameters.

Notice that the WHERE clause of the above example is written in such a way that if the parameters are not supplied by the script, the conditions revert to being comparisons to wildcard characters (which always succeed). This will often be a good strategy where the parameters are essentially optional.

An example of the first use would be:
When I Type: !age
I Really Mean: Sorry, inquiries about age are restricted;Invalid query

In general, the technique for the second type of usage was as follows: a ViewScript (or SpellCheckScript) would detect an "illegal" word or phrase in a query. It would then set the PrivateErrorCode property. An AnswerScript would test the value of PrivateErrorCode and in the appropriate cases set the QueryResult and ErrorMessage propertiess; eg.
    QueryResult = -8
    ErrorMessage = "Sorry, inquiries about age are restricted;Invalid query"

Note that developers using ELF to return results via SQL might find it very useful to embed URLs within the ErrorMessage string; for example,
ErrorMessage = "<A HREF='nwdbmap.gif'>Click here;Click below to see tables & relationships"

Beginning with v4.0, the ErrorMessage string can also be a complex object, formatted to enable Access ELF to return arbitrary recordsets based on its literal contents. More simply put, it's now possible to set ErrorMessage to be a list of row values and optional header values. As an example, let's say we set ErrorMessage to the following value:
"({not available;Just a reminder:};{Something else}); ({2nd row 1};{2nd row 2});"

Access ELF would then return a recordset which appeared as:

Just a reminder:     "We regret to say:"
not available          Something else
2nd row 1             2nd row 2

Notice that the formatting convention is to enclose each cell, or field element, within a pair of braces. The first row can also specify the header for the column (also within the braces, and following a semi-colon). If no header is specified, then the default is used. The default custom error header is defined in the Advanced tab of the Settings window.

Rows after the first can specify headers according to the same format, but this information will be ignored (it will not override the headers specified in the initial line).

Among other uses, we expect that this feature will make it easier to customize lists of URLs which can be suggestions to the user for alternate paths, particularly in cases where scripts find that the application is unable to supply the exact information desired. Note that it would also be possible in Internet/Intranet applications to use this feature to present a list of e-mailable addresses, possibly with topics pre-filled, making it easy for the user to reach parties who could provide the specific information desired.

Public Question As Variant
Public Connection As Variant ' VB ELF only, not used in Access ELF
Public UserID As Variant
Public Password As Variant ' will act as Static by Session
' - - -
Public PrivateErrorCode As Integer
Public SQL As Variant
Public QueryResult As Integer
Public ExecutionError As Integer
Public ErrorMessage As Variant
Public SpellCheck As Integer
Public SpellCheckIn As Variant
Public SpellCheckOut As Variant
Public CurrentViewName As Variant ' 6/00
' - - - 10/2001 (Version 4.0) VBELF compatibility additions:
Public Resource As Variant ' general purpose
Public QueryParms As Variant ' parm-name;parm-value; pairs
Public PhraseTrigger As Variant ' to pass triggers into script
Public DataTrigger As Variant ' to pass data-aware triggers into script
Public NumberTrigger As Variant ' same for numeric value in trigger
Public WarningCode As Integer ' to allow elfClass to display "cautions" in
Public WarningString As Variant ' addition to recordset results
' - - - end 10/2001 (Version 4.0) VBELF compatibility additions

' - - - Access XP extensions:
Public Phrase As Variant ' 12/01; to help construct appropriate warning messages via script
Public DataTrigger2 As Variant ' 12/01; to pass a second data-trigger to script
Public PhraseReplacement As Variant ' 1/02; the text which will replace the PhraseTrigger text
Public QuestionReplacement As Variant ' 1/02; full results of any replacement (including inversions)
' - - - end Access XP extensions

' Public Methods
Public Sub SetDirectoryPath(PathSpec)
Public Function OpenView(ViewName) As Integer
Public Sub AddAttribute(Entry, myAttribute, myType)
Public Sub SelectGrammarLayer(Layer%)
Public Function ExecuteSQLCustom(SQL, Optional whichDB)
Public Sub AppendFunction(Func, Tokentype, domain, Domain2, range)
Public Sub AddVerbMapping(DBName, Table1, Field1, Table2, Field2, LinkVerb)
Public Function Evaluate(thisStatement)

This new version corrects many errors in the initial release. First, note that there was some confusion in the prior release concerning the lifetime of these properties. In the current release, this has been simplified.

Only the Password property acts as static, meaning that it holds its value between queries. This property is designed to allow you to query a user once (and only once) for a valid password. Subsequently, you can simply validate that the Password property continues to hold a valid entry.

Each of the other settable properties is reinitialized (either to an empty string or zero) prior to each question, and any script can read or write these values. (This does not apply to the Connection and UserID properties, which should be considered read-only and always provide the same information, namely the current OLE DB connection string (in VB ELF), and the ID of the current user.)

The Resource property has been added as a holder for any information that scripts might need to pass between themselves. For instance, a ViewScript might detect keywords in the question, and use the Resource string to store these keywords for acting on later (in an AnswerScript) depending on the outcome of the translation.

Use of the QueryParms property is described in Enhancement #1 above. It permits AnswerScripts to return either parameterized SQL statements (a), or the names of parameterized stored queries and procedures (b). The QueryParms property must be filled in by an AnswerScript prior to returning either (a) or (b) as its function result. ELF will then use the "ParmName;ParmValue;" pairs designated in the QueryParms string to replace the names of the SQL parameters with the desired values.

PhraseTriggers, DataTriggers, and NumberTriggers have been added to allow greater customizability of PhraseScripts. PhraseScripts now have access -- in addition to the Question property itself (which holds the complete text of the user's question) -- to whatever context-sensitive triggers were involved in the process of triggering the script. The PhraseTrigger property will always contain the full literal text of that part of the question corresponding to the phrase trigger (the [When I Type] part of a phrase definition). The DataTrigger property will only have a value if the trigger was of a "data-aware" form; that is, containing the name of a field (in curly braces). This part of the trigger is matched by any word contained in the underlying database in the respective field. Similarly, NumberTriggers will have value only for phrase definitions which use the {#} format as an elastic placeholder for any valid numeric value.

WarningCode and WarningString have been provided as another means of passing information back from a script to a client application. Its main purpose is to account for those cases when either a valid recordset or a customized error message is being returned, but additional information may be required by the client. For example, a script may determine that it ought to provide a given recordset as a "best effort" -- even though the meaning of the question may not have been clear. In this case, the WarningCode and WarningString properties could be used to display a cautionary footnote about using the resulting information, or advice on how to create a less ambiguous query.

For example, we use these properties in our Northwind Web demo as follows: an AnswerScript detects the presence of the "PIVOT" keyword in any successful SQL translation. If present, the WarningCode is set to 100 and the WarningString property is set to a caption explaining that crosstabs are also available in SQL Server and Oracle interfaces. The Web ASP page simply tests for non-zero WarningCodes and displays the WarningString above the result if detected. Although this isn't strictly a "warning", it illustrates the potential for using the additional channel for any auxiliary information.

First, we've added two variants of an "include" statement, one which allows scripts to access text from other panels; and one which allows them to access text from external files.

The include statements are of the form:
#include name = "SomePanelName"
#include file = "c:\path\somefilename.xyz"

Include statements should be used at the top of a given panel, to include information from other locations which will be referenced later in the script.

This allows the creation of global functions, which can be used in common by many different types of script. You might find it effective to create small libraries of these functions. In the original release, each script panel was given a name, which was also the name of the function within the script to call when that script was invoked. Library script panels can have arbitrary names; their names don't have to appear as function names. These names are simply used as identifiers to allow other scripts to get access to their contents.

Depending on your taste, you might prefer to keep all your scripts within external files, and have only references to these files within the script panels. In that case, you can use tried-and-true text editors to manipulate script contents. On the other hand, you might prefer to make the text of these scripts directly available to your users via the script panels. To avoid losing any information, you should back up these scripts, which are contained in the elfUserTableTemplates table of the Custom.mdb database. (Note: this is no longer as much as an issue in Access 2002/XP, since the Zoom Box <Shift-F2> can be used to edit script panel contents, without truncating scripts as sometimes happened in prior versions of Access.) You can also edit this table directly, when doing substantial script revisions. One of the truly nice parts about working with scripts is that they stand outside the application -- you can actually modify them while your interface is running and see the results immediately.

While Access ELF has always been a very powerful tool for creating query interfaces, like most natural language systems it had its own built-in limits beyond which "tuning" was difficult, if not impossible. With the addition of scripting in version 3.0, and the substantial modifications made in this v4.0 release, we think Access ELF is reaching a completely new level of customizability.