Broken references in inactive calculations?

[Dave Ramsey]

Currently, FMPerception will flag a broken reference in a calculation definition, even if the calculation has been deactivated.  So, if you have a broken reference in an auto-entry calculation, but the auto entry calculation checkbox has been turned off for that field, FMPerception will still bring it to your attention.

I'm starting to suspect that this is overly aggressive.  I mean, it's technically correct...  The calc is in your database, and the calc has a broken reference...  but do we care?  I *do* remove broken references in deactivated script steps.  So, either way there's an inconsistency.

I'm interested in arguments either direction, but I'm probably most interested for arguments to keep the functionality as it is.  I'm currently inclined to remove these broken references from the broken references results.

Thoughts?

 

Thank you very much.

[ralvy]

Frankly, those references are Broken References, so I like them flagged. However, I'm used to BaseElements, which doesn't flag them. 

Edited August 16, 2016 by ralvy

[dburnham]

How about this compromises:   show it as a broken reference if there is anything in there, active or not, which is broken.   But if there is nothing broken in an inactive calculation, let it be unreported as something broken.

[Dave Ramsey]

21 hours ago, dburnham said:

How about this compromises:   show it as a broken reference if there is anything in there, active or not, which is broken.   But if there is nothing broken in an inactive calculation, let it be unreported as something broken.

That *should* be how it's working now.  An inactive calculation with no broken references should not appear broken.  I would consider anything that responds otherwise to be a bug, and would love to receive a bug report.  :-)

[Dave Ramsey]

The more I dig into this, the more I think the right answer is to ignore references (broken or otherwise) in "unexpressed" code.

I received a DDR via support request that had a value list that used to be dynamically generated from the contents of fields, but is now statically defined.  In the DDR XML, the references to the old fields are still there.  If you deleted one of those fields, now it would be a broken reference, but it really just isn't.  Additionally, based upon the current rules (of considering unexpressed references), that value list is keeping those fields from being "unreferenced"... and that's even harder to justify.

Changing the rules to ignore unpressed references will (I believe) only have an impact on a user who's trying to figure out what the code used to be, while the current rules are having a much broader impact.

While it's going to be a lot of fun to filter them all out, I think they need to go.

 

That said, I'm still interested in impassioned pleas to continue to pay attention to them.

[ralvy]

I did find such a "broken reference" in a Value List because I deleted the referenced field some time after changing that Value List to work off a Custom List instead of a field. To make FMPerception stop flagging that Value List as having a broken reference, I went in and reselected a different field and then reverted back to a Custom List.

I have no problem with getting Broken References to ignore "unexpressed code," as Base Elements does.