Portal vs Repeating

[Del Sauder]

Do I gather that using a Repeating Field(s) for a purchase order will not permit me to produce summary values for specific Item #, i.e. report how many #347 knobs did I purchase last month? Is that not possible to extract from a repeating field, and/or is it thru a portal, or must I generate a separate record for each item on PO to accomplish this?

[Fenton]

You've pretty much hit the problem with repeating fields. They are no good for reports of how many of each item was sold. I mean, you could Find for a particular item, and get some idea that way; but that's a report.

So it's the last two ideas combined, enter the line items in a portal, with the line items records in another file, linked by the PO ID. You can turn on "allow creation of related records" for a simple portal of not too many lines. Or you can have a button to create a new row (could show at the top). Or you can enter values into global fields, then have a "Set" or "Commit" button, which runs a script to create the line item record.

One downside to a separate line items file is that the PO total is now a related calculation, hence Unstored. This can slow down reports which sum all POs (though how often would you really do this?). The last technique, of entering data in globals then scripting creation could, as last step, also set the total into a regular field.

But then you also have to completely trap editing and deletion; it is unreliable unless you have total control. An alternative is to do "batch" setting at report time, of only "finished" POs; or something like that; many alternatives, none of them perfect.

[i wish I wish that FM 7, when it ever arrives, has the ability to store such line item totals, if you include the line item "table" in the same file as its parent; though I hardly see how, since even self-related fields are unstored :-[]