Several other important changes have been incorporated into this release.:

One problem in earlier versions concerned redistributing databases and their associated ELF interfaces. While simple interfaces could be distributed merely by copying the .ELF directory from one computer to another, sometimes the situation was more complicated. Some information was stored centrally (in the ELF32.MDA library file), and this made it difficult to replicate highly customized interfaces without manual import/export. This information included Verbs entered via the Verb Mapper, Scripts, Form Response styles (Favorites).

Finally, some Access ELF users objected to the practice of storing information within the client database, on general design principles.

We've addressed all of these issues by aggregating all information related to an ELF interface within the corresponding .ELF subdirectory. As of version 4.0, everything goes into the same folder. Information that was formerly stored in either the client or ELF library has been relocated into a special Custom.mdb file, found in the .ELF grammar directory. So to migrate a database interface from one machine to another, you now need to copy only the interface directory from the "Search In" directory of the source machine to that of the target machine. This assumes that the same database is already available on each machine; and of course, that Access ELF is installed on both machines.

The downside to this is that there may be some additional work involved in replicating Phrase Substitution lists between Views. We've made this task easier by including two ways to transfer Phrase lists from the old (pre-Version 4.0) elfPhrases tables (contained in the client MDB) and the new Custom.mdb files. One way is to open the Phrase Editor and click the Import button. If the View has already been created, (so the Custom.mdb file exists), then the definitions are transferred. If the View does not yet exist, the definitions are loaded into a temporary table which is transferred as soon as the View is created.

An even easier method of transferring the information is to simply set the AutoImport Preference checkbox to On. This will transfer the information automatically during any Analysis.

It's important to understand that these revisions quite drastically change the requirements for preserving information between analyses. Quite simply, if you erase the .ELF directory, you're erasing all the stored information. This information used to be safely and invisibly held within the ELF32.MDA library file, or within your own database. The information within the .ELF directory was principally information that could be recreated by automated processes. This is no longer true. Information such as scripts and phrase definitions (in other words, developer customizations) are now part of the .ELF package. To preserve this data, you should periodically back up the Custom.mdb file.

In addition to these major changes, there are of course a large number of cosmetic and ease-of-use improvements.

The Save button, which appears on the Custom Analysis form, now stores information related to use of the Master Query option. In previous releases, interfaces relying on a Master Query to define relationships required that this selection was made manually during each analysis. Now all choices that can be made prior to the Analysis are recorded by clicking Save -- including relationship source, excluded tables, and excluded fields.

The capabilities of the data-aware triggers feature of Phrases has been extended. Previous versions of Access ELF documentation reported that, although the marker for resubstituting the data was written as {1}, there was actually no ability to recognize multiple instances of data in a trigger. As of version 4.0, this feature is limited to at most two data-aware triggers per definition. This means that {1} and {2} are the only markers that can be used.

This means that if we install to the Access directory and let the Add-in Manager copy our library to the AddIns directory, we may later find ourselves in the awkward situation of running two copies of the library simultaneously (yielding many mysterious errors caused by uninitialized variables, etc.) This explains why the ELF32.MDA library file is now installed by default into the parent directory of Microsoft Access 2002, where it's effectively invisible to Access!