>The problem is that the users can't see the available fields from the report designer. Brenda is using "Query Maker" which creates a cursor of unknown (to the programmer, in advance) name and structure. The problem with the current report writer ever since VFP3 is that you can't see the data tables or fields in the expression builder of the report designer. This was never a problem in any previous version of Fox. The reports are designed at run time.

>I have the same problem is that I set up, or at least tweak, my reports at "run-time" and I allow reports to be modified at clients sites depending on user security level. And again the cursors that are created are not visible in the expression builder. A real PITA.

>If someone has a workable solution, I'm all ears.

i have found a workaround for my very limited needs. my level of knowledge in this area also very limited, so you probably are already aware of my workaround. ok - enough disclaimers.

if you "create report report1 from tablex", tablex is automatically added to the DE. if you "create report report2 from cursorx", then cursorx is automatically added ot the DE - if all cursorx fields came from the same table. if your cursorx contains fields from different tables, then cursorx is not added to the DE. I found no way to manipulate a report's DE in code.

i always use a table (no cursors or queries) to "create report reportx from tablex". always use the same table name, both as the .dbf and alias. all clients use the same table name, but they each store their table in their own directory or on their c: drive. so the table is their own. the table is added to the DE. the fields are in the expression builders, field listbox. unfortunately the fields are prefixed with the .dbf name. so i use qmaker for my table alias and .dbf. my clients understand that is for query maker. you can choose to delete the .dbf or not. if safety is off it will just overwrite the existing .dbf.

this approach i only use for querymaker. it is for queries and reports that you allow the user to create and change. the actual changes to querymaker where minimal. so far it has worked well. must add that my clients have not given it the "i accidentally spilled my coffee on the keyboard and then pressed backspace and pagedown - what happened?" test.

brenda.