calculated fields problem

[Brewster Gillett]

I'm using A4V4 DOS. For many years. Just had occasion for the first
time to use calculated fields. The results, to put it charitably,
are not reassuring. The calculation in this instance is extremely
simple - just dividing one numerical field's value by another
numerical field's value - with the foreknowledge BTW that all
results are guaranteed to be positive numbers only, formatted
to one decimal place.

So - I get *three* different answers in three different places,
none of which are accurate. F7 (test while creating the expression)
gives one (wrong) result, the screen gives nothing but a row
of questionmarks, and the report print gives garbage which is
mathematically incorrect.

So what is the arcane secret for successful calculated fields
that I have apparently overlooked? I've RTFM not once or twice
but several times - I've verified what operator symbol is used
in an expression when dividing - I've looked for "format"
whizzies which I may be omitting - and nothing.

Anyone have any ideas?

Alpha is apparently in the process of relocating, and their
support staff are completely unavailable. None of the numbers
you can call, including their main line, do anything but
eventually dump your call back into the ether.

I love the software, but am becoming somewhat unimpressed
with their support committment.


Brewster Gillett
[email protected]

[Keith George]

RE: calculated fields problem

Hi Brewster,

If the fields are numeric, it should be a simple field3=field1/field2.

Are you sure all the fields are numeric?

Keith (Cornwall UK)

[Brewster Gillett]

RE: calculated fields problem

Yes, they're all numeric.

I get the impression from your message that the expression needs
to lead with the target fieldname - the manual examples do not
seem to indicate such, so I did not craft the expression that way.
Since when you are creating the calc field you are doing it *from*
that field, it would seem unnecessary to invoke the field name as the
lead expression element, but I'll try it that way.

Thanks for your response.

Brewster

[DSG]

RE: calculated fields problem

Brewster;
The reasons for your "incorrect" answers could be several. If you could provide a little more information, we might be able to narrow down the problem. For example, what section of the report is your calculated field found in i.e. detail, or summary, or is it in a group section? Are you trying to calculate a total, or an average or some other data type? Any further detail you could provide would be helpful to address your question.

Duncan Greenshields

[crimmelcp]

RE: calculated fields problem

Brewster:
Sometimes when I do calc fields, I find it easier to just add the fields to the database.
In your case add them as numeric 10,2
make them a calculated field in the field rules and add the formula.( field1/field2)
choose and open the database and browse the records.
scroll over to the new fields so you can see them.
press the "C" to change, arrow down to the other records and see if the field calculates correctly.
If it does, then all you have to do is to print the field in the report.

Sometimes this method works better than using calc fields in reports.
you can also craete a global update to reclaculate the fields without going to the browse screen.
Charlie Crimmel

[Brewster Gillett]

RE: calculated fields problem

My intent was to have the caculated field as part of the database,
as a subsequent respondent has suggested. In this specific instance
the calculated field is not intended to form a total, or be a part of
any summary - it simply is a ratio expression based on the
division of one of the existing fields (weight) by another (horsepower).
Naturally I wish to be able to sort on it in an appropriate order
just like any other field. And I figured that if it's in the database,
then naturally it would appear in any reports I would generate.
I am beginning to suspect that I may have been in error :-)


Brewster

[Brewster Gillett]

RE: calculated fields problem

Adding it to the db *is* what I was attempting.

Why 10,2?

I'll try that "CHANGE" sequence you mention to see if that
will produce the right figures. Using a Global Update did
not.

I confess to being a trifle mystified as to how a simple
division of one numeric field by another could produce
such wildly inaccurate results.

Thanks for your reply.


Brewster

[DSG]

RE: calculated fields problem

Brewster;
It sounds like the field length for your calculated field has not been set large enough. Try reconfiguring the data base to enlarge the field by several spaces (also remember the decimal point counts as 1 space). I suspect this will solve your issue, as a too short field length will give you **** in a browse table and ???? in the actuial data field.

I am also wondering about the incorrect answers you get when pressing F7. By any chance were you within a "search" when using F7? The reason I ask is that even though the record you are looking at is #245 for example, I believe that when you press F7, the programme starts at record #1 and then progresses record by record. So while it would appear that F7 is giving the incorrect answer, it is really referencing a different record.

I hope this might help.

Duncan

[Mike Konoff]

RE: calculated fields problem

What are the names of your fields? What are they set to, including type, such as character or number, and their width and decimals, if numeric? Also, please include some sample data examples that were providing you with different results and also list the different answers that you received in different places.

From what you stated previously, you want to enter data in two particular fields and have the result automatically determined in a third field. If so, you'll need 3 fields. I'll assume that you have them as actual fields in your table.

Let's assume the name's of your fields are what you provided above...weight, horsepower, ratio.

For the field rules of the table you'll need to set the field "ratio" to calculated. It's expression should be simply enough "weight/horsepower".

You should get the correct answer. Also, on your form, check that the format of your fields match that of how your fields are formatted in the table, including matching the decimal places.

Mike

[Edwin Spencer]

RE: calculated fields problem

The best way to test calculated fields is to set up a test database
with only a few records. Have record 1 to calculate to the value of
1, record 2 to the value of 2, etc. This way you know what the
results should be for each record. When you press F7 to check the
calculations Alpha starts with the first record in the database.
Yes, you can use the calculated field on forms & reports. In the
default setting, do you have the Recalculation mode set to Automatic?
Edwin Spencer
[email protected]