Andy- You bring up some good points; I'll chime in here with some clarifications about the session material.
I think the limitations lie more with the infrastructure requirements and business factors than they do with target audiences, per se. Because English Query requires a SQL Server license, that immediately places a lower bound on the type of systems that will benefit from it, at least from a size and economy standpoint. Systems with smaller datasets, or which are purely desktop-oriented are probably not good candidates. I think that your idea of a generalized ad-hoc reporting interface, if carefully controlled to prevent possible cartesian joins and other bad things, is a perfectly good way to attack the problem. For systems that already have SQL Server-based data warehouses, the English Query approach offers considerable upside. You allude to the need for ad-hoc reporting; building an effective ad-hoc reporting engine is very, very difficult and needs constant care. Because it is code-bound, it is, by definition, limited to handling only what the developer makes available to the interface. The natural language understanding approach is entirely different: by defining a semantic model on top of the data, the engine will translate English requests into SQL calls. This "translation" capability is very sophisticated, and I have only scratched it's surface. A non-technical person can be trained to do a lot of the modeling; in fact, it's preferred that a subject matter expert, rather than a technical person, do this. A well-setup system can answer unanticipated ad-hoc queries, including complex and even abstract requests, quite well. You *can* work with systems that are poorly normalized or have a poor RI scheme; it's just more ramp-up work on the front end. Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Davies Sent: Wednesday, September 20, 2006 6:28 AM To: [EMAIL PROTECTED] Subject: Re: Creating VFP reports by end-users Hi, I had a look at the "English Query" session stuff on the link posted by Dave Bernard and it reconfirmed my prejudices <s>: it's aimed at v. high level users ("CEO's") it needs a *lot* of preparatory work to make it go (at all) for starters it needs "well normalised dbs's that max. the use of PK / FK's to relate the tables" - - in my experience a lot of commercial systems just don't have the RI (they grew from access/dBase flat file systems; the RI was a problem during data take-on and never put back; w.h.y) I've spent quite a lot of time thinking/ planning about this so ottomh: you probably need metadata / a data dictionary of some sort for table relationships and 'friendly' field names. even then it won't work unless the users have a good understanding of the data the system uses (rare!) given that: present the user with list(s) of the fields they're likely to want and a field picker and optionally an expresion builder. hack some code to put in default formating (trim blanks, handle nulls, format dates, cast numbers <-> characters, etc) and to handle the joins. create a query that creates *one* cursor for the report, optionally allow saving/ editing of queries**. try and pre-format a report for maximum page width (>= A3 landscape <g>) and create a 'Quick Query' type layout from the cursor (this has been a big stumbling block for my efforts). put the report designer/ report controls toolbars on the users' menu. modi repo && you're away ! ** As Dave Crozier mentioned in an earlier post I have looked at trying to automate Microsoft Query (which imho opinion has a really good ui) but with no success - so if anyone knows how to... Andrew Davies MBCS CITP _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
