
1. Re: Evaluate
philmodjunk Aug 26, 2013 9:15 AM (in response to tays01s)How's that again?
Can you post an example of what calculations you are trying to work with? And explain why you need to store them in a table and use Evaluate with them?
You shouldn't need to make duplicate tables and your reason for not using different TO's of one table does not make any sense to me.

2. Re: Evaluate
tays01s Aug 26, 2013 9:53 AM (in response to tays01s)I don't think seeing the calculations would help. The problem I have is that the 2 fields doing evaluations for different parameters have their equation selected by a value list and both lists are based on the _EquationID. So if I used wanted ID no. 2 for parameter A I'd get the equation for ID no. 2 for parameter B as well because they happen to be on the same record whereas I'd like to select them independently (though as mentioned, it would be nice to have these equations grouped on 1 table).

3. Re: Evaluate
philmodjunk Aug 27, 2013 8:58 AM (in response to tays01s)Ok, trying to parse that: You have a text field for the equation and you have a primary key: _EquationID. And are your parameters drawn from fields in that same record?
The issue being that you get all the parameter fields visible on your layout whether you use them or not?
Say you have two equations: Length * Width * Height for equation 1 and Length * Width for equation 2. When you pull up the record for Equation 2, you see a field for Height even though Equation 2 does not use that parameter?
There are a number of ways to selectively display the fields for entering your parameters. With just two equations, you might have two tabs in a tab control and then one tab shows the fields needed for equation 1 and another shows the fields for Equation 2.
It's also possible to set up a table of related records for the paramters with a portal displaying a record for each parameter. Each such record has three fields, an equation ID, a parameter label field and field for entering the value. This adds a lot of complexity to feeding this info into your equation so that it can be evaluated, but it allows you to display different sets of records to control which values are needed for each equation.

4. Re: Evaluate
tays01s Aug 27, 2013 1:52 PM (in response to tays01s)Q1. You seem to have answered a different Evaluate Q I was posing, but can I continue your response;
 Yes, I just want to display the parameters for a specific Equation and since there are scores it's your last paragragh that's important. Are you suggesting having:
 Table: Equation: To hold __EqID(pk), Eq_name, Eq_equation
 Table: Parameters: related to the above using _EqID(fk), a field per parameter label + field per parameter dialogue box.
Would I then put fields from both into a single portal or separate?
Q2. The Q I was asking in this thread was whether I could hold a set of Energy equations and Protein equations on the same table as outlined above or should I separate them into different tables because a record could call up Energy Eq2 but I might want to combine this with Protein Eq14 ; I assume 2 popups dealing with Energy and Protein in the same portal would 'contradict' each other.
Info:
Table: Equation: __EquationID, Eq_name_text, Equation_Text.
Table: Calc: _EquationID (fk), EvaluateField.
Relationship: Calc > Equation (since the same equation may be used in many calcs).

5. Re: Evaluate
philmodjunk Aug 27, 2013 2:41 PM (in response to tays01s)I assume 2 popups dealing with Energy and Protein in the same portal would 'contradict' each other.
Of course they would but you do not need separate tables to have a different portal for each equation since each will have unique equation ID's.
You might even be able to set up a set of relationships like this:
MainTable<Equations<Parameters
A list view layout based on Equations can include data from MainTable in layout parts other than the body such as the header, a leading grand summary or a sub summary layout part. The equations can be listed in the bodyone equation to each record and then you can put a portal to Paramters in the body for listing the appropriate parameters for each equation.

6. Re: Evaluate
tays01s Aug 28, 2013 1:03 PM (in response to tays01s)1st para: So is it a choice to keep a single table of equations with different IDs for each but have different portals for each equation, or have a table for each equation and then these could go within the same portal?
If my tables are: Calc, Equations, Parameters, I can understand Equations > Parameters, but since any given equation may get applied to several Calcs, won't it be Calc > Equations?
Re. Parameters portal, isn't the problem that I don't just need a record to contain the parameter data entry fields, but also the labels. This would then mean a Labels table with a labels portal?
Could an alternative to my paragraph above be to have a Parameters table with Label and DataEntry fields that could be portal filtered by another field. That way the portal could take less width and be scrolled. I just haven't thought of how to filter.

7. Re: Evaluate
philmodjunk Aug 28, 2013 4:26 PM (in response to tays01s)1) I believe that was the question you were asking and no I would not use different tables for the different equations in most cases, but this is not something that has a hard and fast rule for one over the other.
2) my example is perhaps overly simplified.. You may need many more tables and table occurrences here. One set documents each equation in the idealthe expression and the needed list of parameters would be two tables and then the selected equations and actual parameter values would be a second pair of tables and expressions. I've only shown the latter here in this thread. I think that's where you're headed with your question about a "labels" table.