>By completely ad hoc, you mean one where a naive user could report on data whose structure was not already in your data dictionary?
>
>Also the last time I looked at Foxfire -- if users got to choose ANDS or ORs in a query they did this by inputting AND or OR. Has this changed? Or was this one of the things you coded around?
>
>Thanks
>

Gar,

If the data dictionary defines the entire database schema then the user has the entire schema for inclusion as well as selection criteria. The users refer to things by names they understand, not table field name references. For example, the user would select Total Sales from a list, that name was related to the joins conditions required to get the sales figures out of other tables and relate them to the tables required for the other fields requested. The joins are predefined for each available field so the user selecting a field automatically creates all of the joins required to obtain that field.

As for AND and OR, every dialog if developer replaceable with your own dialog. We predefined a bucnh of common criteria selection dialogs and the users could use them for about 98% of the queries they ever did. For those users sophisticated engough, the built in dialogs gave them what they needed to define the other 2% of the queries, which if they requested would be added as included named criteria.

Foxfire certainly doesn't do this with magic. It took a few months of developer work to get the schema defiend correctly. A few more months to build the modifications we added so the users could click a button in one of our screens and get a report without ever seeing Foxfire on screen. We also modified foxfire so we could call it and pass it the fields, criteria, and report form we wanted it to use. We also added the ability for foxfire to return it results as a cursor rather than a report so we could use it from our code to do other things we needed to do.

This was all done in FPW 2.6 a few years ago. I am sure foxfire has added many of the things we did to their product.