Just a quick question: are there any drawbacks of using unstored calculations as dataproviders to access the columns that are more than one relation away from the current table? Essentially such a calculation does not calculate anything but provides access to related tables without having to load the records in form by query or something. Is it a good practice/bad practice/doesn’t really matter? Thanks.
It depends. When you only want to display deeper related data you can use a label and concatenate the relations together in the text property as a merge code to get to the table you want in the same manner you would in a calculation.
%%relation1.relation2.relation3.columnName%%
You just need to make sure that the property DisplayTags is enabled on this label.
When would you use a calculation ?
I can think of 2 situations where you would use a calc instead.
You want to format the data (date, number). A label doesn’t have a formatting property. Fields do.
You are using this related field in many places so it’s just easier to have it as a calc so you can simply select it instead of writing out those relations each time you need it when you are developing.
Any drawbacks ?
Calcs are known to sometimes trigger more than once (yes they still do Johan!) but the cost of that should be minimal.
A problem occurs with a few of my calculations.
I’m calling databaseManager.recalculate() method to recalculate a value for a calculated field.
Before I call the method from the form I check if the relation works (which is used in the calc); the relation is there and contains one record.
But when I go in the calc itself it does not see the relation (“Error: ‘productpricing_to_product’ is not defined”) gives an error and jumps out of the method.
I understand this is not form access which is not recommended from calcs. What can this be?
I cannot use a form variable here and put all calculations in the form methods because the form is in the table view and the value must be different for each row.
Please, help.
jmeunier:
You should probably check if there are records in the relation in calculation code before using it in the calculation. Something similar to this:
if(databaseManager.hasRecords(relationname)){
//now work with your relation since you are sure it has records
}
Hope this helps.
Jason
What I do is check if the relation is not null: productpricing_to_product != null.
And it’s not null, however debugging in the calculation code does not show the values of local fields either. Until I assign the value of a field to a local calc variable. That’s kind of strange.
I agree with Robert. One more drawback we have found is a stored calc (in our app) needing 2 days to recalc and we never found out why it takes such a long time. I can not rule out the possibibility that it has something to do with the database, though.
We use if (relation && relation.getSize() > 0) to verify the existance of the relation and make sure it has related records.
Best regards, Robert
PS: Can someone from experience tell that databaseManager.hasRecords(relationname) is exactly the same as the above check? At least a while back I did not under all circumstances get the same result so we still use relation && relation.getSize(). But may we can savely change to databaseManager.hasRecords(relationname) now, but would be happy to hear other oppinions.
maria:
A problem occurs with a few of my calculations.
I’m calling databaseManager.recalculate() method to recalculate a value for a calculated field.
Before I call the method from the form I check if the relation works (which is used in the calc); the relation is there and contains one record.
But when I go in the calc itself it does not see the relation (“Error: ‘productpricing_to_product’ is not defined”) gives an error and jumps out of the method.
I understand this is not form access which is not recommended from calcs. What can this be?
I cannot use a form variable here and put all calculations in the form methods because the form is in the table view and the value must be different for each row.
Please, help.