We have reset all users FileMaker related profile fields. Please take the opportunity to update your information,  this will provide background to members whom read your posts. Click here.

Jump to content
Dave Ramsey

Broken references in inactive calculations?

Recommended Posts

Dave Ramsey    1

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.

Share this post


Link to post
Share on other sites
ralvy    0

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

Edited by ralvy

Share this post


Link to post
Share on other sites
dburnham    0

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.

Share this post


Link to post
Share on other sites
Dave Ramsey    1
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.  :-)

Share this post


Link to post
Share on other sites
Dave Ramsey    1

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.

Share this post


Link to post
Share on other sites
ralvy    0

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×