Q) Is it possible to distribute Access ELF with my Access RunTime projects? If so, is this legal?
A)
Not only is it possible, but with our new licensing policy, it's completely free (and hassle-free). Because the Access ELF installation program is now fully redistributable, you don't even have to keep track of your distributions.
Follow these steps to include Access ELF with an application distributed with Microsoft's Access RunTime. (We'll talk about the simplest possible scenario, you can take it from there.) First, place a copy of the Access ELF library file, elf32.mda, into the same directory as the database you'll be distributing. For the purposes of this example, let's call it Northwind.) Open Northwind.mdb and open any module, then click Tools/References. Add a reference to Access ELF by browsing to the elf32.mda file now located in the same directory. If there's already a reference to elf32 (located in the AddIns directory of the development machine) remove this reference first, then add a reference to the "local" copy.
Step two is to make sure that there's a way to get to Access ELF's dialogs. In a RunTime situation, you can't start Access ELF from the AddIns menu. The best way is to import the Access ELF Toolbar directly into your application. To do this, use the Microsoft Access File/Get External Data/Import dialog. Open elf32.mda and, on the Import Objects window, click the Options >> button. Check off "Menus and Toolbars", uncheck "Relationships". That's it, you don't need to select anything from the Tables . . . Modules tabs. Just click OK and you're done. Now you can control when the Access ELF toolbar appears by setting the Toolbar property of any form in your application to "Access ELF".
Of course, when packaging your application using the Package Wizard, you should include elf32.mda. The Access ELF installation will also need to be performed on all client machines. You can either make this an integral part of your installation, or just instruct users to download and run the ACCELFXP.EXE installer.
The only features of Access ELF that will not operate in the RunTime environment are those features of Access itself which are disabled. For instance, you cannot use the Edit button from the Worksheet to open Microsoft's Query Designer, because the Designer is incompatible with RunTime mode. Another feature that Microsoft has seen fit to disable is the ability to adjust column widths. Because of this, the Best Fit checkbox on the Responses tab of Settings will have no effect.
We also recommend using the "Current Directory" choice for the Search In directory. This will simplify the process of distributing interfaces, since the .ELF folder(s) can then be placed in your application's own directory. However, if you wanted to centralize all .ELF folders (for multiple applications running under RunTime) you'd only need to make sure to create an empty ELF -- not .ELF (dot ELF) -- directory in the RunTime's home directory. That would probably be c:\\Program Files\Common Files\Microsoft Shared\Access Runtime\Office10\ELF.
Q) How can I use Access ELF with replicated databases?
A)
The installation procedure for replicated databases is a little different than the usual. You can't install Access ELF on a Replica of a database, only on the Master. To move Access ELF into the Replica, you must synchronize the two copies. Once this has been done, Access ELF can be started within a Replica normally, by using the Add-Ins menu from the Tools dropdown.
Before beginning the synchronization, you should check to make sure that there are no queries in the Master that have the "elfQ" prefix (or any Custom prefix you choose on the Advanced tab). These queries are temporary work queries, which are usually deleted when closing down the system. If you've just used Access ELF within the Master (for example, to test), then some elfQ queries will show up in the Queries tab of your Access database window. You must delete these prior to the synchronization, or the Replica will be unable to store its own on-the-fly queries. (In other words, natural language questions won't work in the Replica.)
Once Access ELF is installed into the Replica in this way, you have complete flexibility as to where the analysis is performed. You can run analyses on the Master, then publish them by sending the .ELF directory to your clients. If you prefer, the analysis can be run on the replicated copy. Or you can provide a "suggested" interface with your application, but allow your users to wield all the customization tools built into the program at their option.
Access ELF will ignore the "Replica of" part of any database name, so you won't have to go to any special trouble to get replicas to recognize Views created in a Master, or vice-versa. However, if you have a different naming system for your replicas, you'll need to take reasonable precautions to make sure that Views you create for distributed replicas are recognized as belonging to that replica. For instance, if you make a replica of Northwind called NWCopy, the name of the View that Access ELF expects to find for that replica is "NWCopy". This means that you'd probably want to name the View you publish with this replica "NWCopy". Especially if your users don't have their own Access ELF license keys -- because the redistributable key is held within the View (which Access ELF won't otherwise be able to locate).
Another issue is that, with this kind of private naming scheme, Access ELF can't know for sure which of the Views in a directory are actually related to the open database. (This only makes a difference to which Views are shown on the Views tab with the Show Views matching this Database only checkbox set. It doesn't affect which Views can be loaded, because any View can be loaded by any database.) The compromise we use is to consult the Title property of the Database Properties Summary tab. If the two match (as they normally will for a Master and Replica) we'll assume they're related.
This works beautifully for the situation where you're publishing replicas and related Views. In the opposite case, where a client has created a View off one of your published replicas -- and, say, emails it back to you for debugging assistance -- the View won't appear in your View list. But in this case you know exactly what View you're looking for anyway. Just uncheck the "Show Views matching . . . box to find and load the problem View.
By default, Access ELF will set the field status of the following replication fields to NoAck (Do Not Acknowledge) during the analysis process: s_GUID, s_ColLineage, s_Generation, s_Lineage. This assumes that you will not normally want to make natural language inquiries about the system data used to implement replication. If this assumption is wrong and you're doing some special "meta-programming" experiment, reset the field status using the Field Selection window.
Here's one more suggestion for working with replicated databases. Assuming that no special customizations have been made on one copy, and that the data involved has not changed since synchronization, the same questions should be answered in the same way on either copy. If you find there is a difference, the first thing to try is to rerun both analyses with the Use Statistical Sampling option set to No. This will smooth out any differences due to conflicting "guesses" during the respective analyses.