Here is what I was envisioning:

-- Data entry tabs and other layouts for data entry or editing

-- Reports or forms that print out from populated data (many related tables)

My users are accustomed to being able to edit reports/forms prior to printing. Is that normal?

It gets complicated, because of portals (containing historical data) and other things that I have yet to implement and have no idea how that would work if they enter straight onto the form.

Can I lock down the forms, so if any data entering or editing has to be done via the data entry layout? What are the “best practices” or recommendation or plain ole good advice?

Thanks bunches

Edited June 1, 200619 yr by Guest

was wondering if this actually was posted? 2nd try to post.

Sorry if confused

Personally, I don't really like the idea of users editing forms or report layouts (I don't allow it in my solutions.) Aside from the unorganized print-outs this could result in, there are also security concerns if the field access privileges aren't carefully controlled. On the other hand, I also don't like having to be the one to make minor changes to forms and reports based on whatever minor variations a user need at the time.

A possible solution to this trade-off between developer control and end-user customization is to have a couple generic reports that allow user-customization in a controlled framework. This can be done by allowing them to choose what fields they wish to view by selecting from value lists, and then showing the content of the selected fields with calcs utilizing the getfield() function.

Attached is a basic example of this technique. I haven't put the functionality in there to handle reverse sorting or correctly sorting field types other than text, but it's not too difficult to add.

DynamicReport.fp7.zip