I am having a strange problem accessing related unstored calcs. Here is a simplified version of code that I'm having the problem with. This is just a small chunck of code from a much larger page.

$projects = $contract->getRelatedSet('Company to CustomerContract to Projects'); // an array of contact record objects

if( !FileMaker::isError($projects) ) {

$i = 0;

foreach ($projects as $project) {

$id = $project->getField('Company to CustomerContract to Projects::ProjectID');

$title = $project->getField('Company to CustomerContract to Projects::ProjectTitle');

$total = $project->getField('Company to CustomerContract to Projects::JobServicePriceTotal');

$total_tax = $project->getField('Company to CustomerContract to Projects::TaxTotal');

}//end foreach

}//end if

At this point in the code the total and tax fields are = to "0" for the first record and = "" for subsequent records. The stored values like Title work fine. Anyone have any ideas what the problem might be? I checked all the permission to the tables involved and they are all wide open. Is there a known bug with accessing unstored related data? Any help would be great.

Edited June 26, 200718 yr by Guest

While I know nothing about PHP, must this be basic knowledge to every developer, unstored fields out of sight holds no value ...by out of sight means, no rendering of a layout to pull the evaluation, well no value!

--sd

I understand your reasoning, but there is a layout based on the Contract and a Portal showing the Projects. The php query is looking at that layout. That layout shows the values I need when viewing via FMP.

... are you trying to retreive data from a portal or one related record per primary record?

Edited June 27, 200718 yr by Guest

unstored fields out of sight holds no value

I think thats a misstatement Soren. Unstored calcs evaluate whenever they need to, it's just that coincidental that they need to when on the layout -- try the data viewer, or using an unstored calc in another unstored calc.

whenever they need to

Yes perhaps it's a better way to express it. But say you have a unstored calc, in a related table dependent on a global ...here is the trick to move the global field into the related table instead, and then make it visible in the viewer table ...although it belong to a different talbe.

using an unstored calc in another unstored calc

Just a spiffy question, how is it's value getting to you knowledge ...by a layout? My statement might unintendet have ignored chained dependencies, if you have a unstored field relying on unstored values over the thresshold a relation ...is there likely to occure some freshing issues. Why have the DV a fresher button in the first place??

--sd

Well, the unstored calc is really unstored except in it's representation on a layout... what is displayed is simply a temporary representation of what was calculated at the time the calculation requirement was triggered -- i.e. the layout refreshed.

Anyway, the point i'm trying to make is that if you call an unstored calc which is on a layout (which it has to be anyway if you want to call it through the PHP interface), no matter what that unstored calc is evaluating (be it other unstored fields, or related unstored calcs etc) it will return the appropriate value