The Case statement maybe a better choice - it is equivalent to an if else statment. http://www.google.com/search?q=filemaker+case+if+elee
I always use a Case Statement, even if I think there will only ever be one test of if, true, false. It is the same number of keystrokes, the same syntax to learn, but if ever I do want to add another condition it is immediately available. All tiny points, however.
For reference, your IF statement should be, as you say, test, result if true, result if false. Your statement was:
If (Product; "YO2"; Prod YO2 = Cases,""), so the test part was just 'Product'. Then you seem to have used a comma as a separator and not a semi-colon.
I think what you meant was "If the field 'Product' contains the text 'YO2' then make the data in field 'Prod YO2' set to the taxt 'Cases', and if it isn't, set the field to be blank. If that is the case then it is the field definition for the field 'Prod YO2'.
If that is what you wanted it should have read:
If ( Product = "YO2" ; "Cases" ; "" )
If ( test ; Set to 'Cases' if True ; Set to blank if false )
Defining a separate calculation field for each type of product seems like a tremendous amount of work to produce a result that isn't very flexible. (Add a new product to your inventory and you have to define another field, update the layout...)
Computing inventory can probably be accomplished much more smoothly with a summary report and summary fields that don't use any such specialized calculation fields. It can also be done with a Sum calculation instead of a summary field, if you have the right tables and relationship.
Sorbsbuster thanks for the solution. Obviously, now, the book I was using gave misleading syntax. PhilModJunk, you are right, giving each product it's own field requires a lot of extra work, but the company is run by a bunch of bean counters who want to track every aspect of each component of the the product from the mine thru manufacturing, packaging, shipment and to the store shelves. But in today's economy, it makes for my job security! Any way, thanks to the both of you for helpful information.
The company...want[s] to track every aspect of each component of the the product from the mine thru manufacturing, packaging, shipment and to the store shelves
You do not need customized, separate fields for this. This can all be done with other methods that avoid the pitfalls and complications of this approach.
PhilModJunk, : You do not need customized, separate fields for this. This can all be done with other methods that avoid the pitfalls and complications of this approach
Sounds good. Can you name some of those other methods so I can read up on them? Thanks
First take a look at this simplified demo file as a starting point. It was uploaded to a different FileMaker Forum by someone named Comment in that forum:
Note how you have a product table for documenting data specific to a given product and a LineItems table for documenting each time an item from the products table is sold. Purchase orders and Bills of Materials may be structured in much the same fashion but with different tables in most cases.
With this basic approach, you have one and only one record for each finished product. If you need to track the components used to manufacture that product, you can link it to a table (for a bill of materials) where you can list each product and the needed details for documenting the information about it.
The key factor in all cases here is that you have one record with one ID number for any given "item". That item can be a finished product, a component used to manufacture it, a price list entry, a purchase order entry or a bill of materials entry, but the same one to many relationship with (in more cases than not, a portal for viewing the related component items) is used.