Table::_FIELD1_ < .095 and > .105 or
You need to repeat the field, as in:
Table::_FIELD1_ < .095 and Table::_FIELD1_ > .105 or ...
But how can Field1 be less than .095 AND greater than .105? It will always fail, right because it can't meet both conditions?
TY! I see I needed to repeat "Table::_FIELD1_".
And yes your right! The value is less than OR greater than.
BTW, I feel I must tell you that using multiple 'like' fields indicates that they should be records instead of fields. What happens when your business need changes and you want to add another test? And even this simple calculation points to complicating your design beyond necessary. It should really be: FIELD < .095 and FIELD > .105.
The same holds true for your FieldA, FieldB and FieldC. I hate to bring bad news (and I've been bopped in the nose by folks who haven't wanted to hear it). I was told once that if I couldn't say something good or bring good news that I should shut up LOL. So the good news is that, if you open yourself to restructure, designing will become MUCH simpler and you won't keep hitting the kinds of roadblocks you are hitting.
Any time you find yourself adding multiple 'like' fields, it is a sign that they should be records in a related table. Dead giveaway ... fields that end in sequential numbers.
TY again. If I understand you correctly when pertaining to "fields that end in sequential numbers" if that is in reference to the field names; I didn't post the actual fields names. The calculations are being used to analyze data orginated from another source. The data is not ever modified.
I'm unclear of your suggestion of "multiple "like" fields. I do appreciate any advice and tips offered.
You have several fields which contain similar data. I know this because you, in your example, are addressing fields with < .095 or > .105 so five fields have similar data. This is how I know. It doesn't matter about the field name but I would bet these fields have similar names (or meanings).
I gave you the tip ... stop designing, regroup, move those fields to records (in this example, you would have five records and the Type of the record would probably be the true field name or meaning. I know you base is incorrect but I cannot provide further suggestions without seeing the file itself.
Thanks. I agree; without seeing the file itself it may be beyond a forum that I can resolve this issue as this is just a very small script/condition of a much larger function created in filemaker. Moving the fields to records will have to take a large degree of analysis on the file and function of this application in regrouping and redesign beyond the scope of the forum.
For testing purposes: in Layout Mode > Format > Conditional Formatting. I tried to format fields to either fill color or change font color using the "not between" condition or "less than" or "greater than" condition to identify fields that are < 0.095 and fields > 0.105.
Is there a source that has detailed information on how specifically each condition in the Conditional Formatting function of Filemaker operates? ie: are conditions all applicable to both numerics and character fields? If numerics.. are there specific formats that are applicable? Decimal applicable? etc..
In some cases a testing protocol will require x number of samplings. Rather than have each sampling as an individual record and try and control those relationships and record counts. Its simply easier to make them individual fields within a single test record.
It looks like thats whats happening here.
However if the application were to handle different testing protocols with similar data collection it would be better to translate the samplings to individual records.
Just ignore me if this isnt the case :)