HI, I have an existing field which is a lookup upon creation and used in relationships .. however the field that it looksup can change and I've now decided (after 6 years !) that I want it to reflect the value of the lookup field as it is (dynamically).  what are the consequences of changing the field from a number field to a calculation field .. apart from some possible slowness loading layouts

regards

Cate

 

More details would be useful, especially how this field is being used in relationships. An unstored calculation field cannot be used as the matchfield on the "child" side of a relationship - more precisely, the side from which the relationship retrieves the related record/s. In some cases there are workarounds that can be employed to overcome this limitation.

Hi Comment,   the field is always the parent side of the relationships for the purpose of this question

 

the problem has arisen thus

 

Case::BranchID is initially assigned based on the branch ID of the get(accountname) of the person creating the record (case)

the Invoice::BranchID  is a numerical field lookup from the case:branchID upon it's [invoice]  creation

BUT, we've recently embarked on the paperless office thingy whereby other branches can create cases and invoices for the other branches.  So if the case::branchID changes after the invoice creation then the lookup field invoice::BranchID remains as it was created .. which is a prob as the invoice needs to be attributed to the newly assigned  branch

so I was thinking of just changing the invoice:branchID from a numeric [lookup] field to a calc field ... there a number of child relationships attached to the invoice::branchID field and I was just wondering whether there is anything that the change in parent field type might affect

 

I've played around with a backup copy and couldn't see any obvious probs, but thought it best to throw it out there given I'm only the in-house, part time programmer for our small family company

  regards

Cate