Broken References

[William Slim]

Hi all,

Figures for broken references differ completely on the Report Card vs the 'Broken References' node if FMPerception. Some figures, such as 'Impacted Layouts' are empty in the report card '--' yet may have '24' in the Broken Refs node.

What is the difference between them/how should they be interpreted? 

I'm guessing the node should be relied upon but I'm having difficulty tying up figures between the two even at a headline level. In this particular instance: 'Fields Impacted' on the report card states '15' yet <Field Missing> and 'Empty Field Reference' are both in the 60's.

Thanks in advance,

Lee

 

[Dave Ramsey]

Hey, Lee.  Great question.

The Broken References top level query is organized by the kind of error that is encountered, but provides very little assistance for where there errors are encountered.  So, for example, an "Empty Layout Reference" is commonly found in a Go To Layout or Go To Related Record step that was pointed to a layout that no longer exists...  But that could appear in any of the following:

• Script step
• Single step layout object button 
• Single step Menu item

So, if you wanted to fix all the "Empty Layout Reference" items, you might have to go all over the place to do it.  Some users requested the ability to tackle broken references by where they occur, rather than by type of error.  So, "let me go to a particular layout and fix all the issues there (regardless of the kind of issue) before moving to another layout."  The Report Card breakdown of Broken References is designed to assist with this.  Additionally, I can use my own knowledge of a system to filter that list.  So, if I have a bunch of Impacted Layouts, I can click on that to look at the layout list.  The names of those layouts may tell me that I don't have to prioritize fixing these, as I tagged the Layout names with "[DEPRECATED]" (my personal favorite code for tagging items that are not in use, but that I haven't gotten around to deleting yet). Or, all issues may be on my Main Menu layout...  A serious problem that I should address immediately, one way or another.

The behavior difference between the two lists is also more in line with how I see the Report Card working.  If I'm about to sit down with a customer, a sense of what user elements are effected by this issue is far more useful to me than a technical explanation of the kinds of issues.

So, in the end, if those numbers match between the two different representations of Broken References, it is purely coincidental, because they're reporting two different things.

 

If that does not answer your question, please let me know.

[William Slim]

Hi Dave,

Thanks for your explanation. I should have said what I was trying to do:

After initial analysis of a DDR for a system I'd like to say to a client: "We've found 'X' issues in your system that may need fixing/investigating" - initially I thought the Report Card did this, reconsidering, and from what you've said, I see the Report Card (broken references) shows the number of actual items affected - (counting unique instances of script names seems to confirm this). 

Also caution should be taken when looking at say: Impacted Layouts 0%  (there may be many layout object issues that indirectly affect layouts)

So to get the total number of occurrences of issues, you'd need to extract that from the Broken Refs node.

(correct me if I'm wrong)

[Dave Ramsey]

Yes, you are correct that some of the issues might have indirect references.  For example, if a script has a problem, it might be inferred that any layout (or menu item, or other script) that calls that script also has a problem... But that's beyond the scope of the current functionality.  What I don't want to do is tell a user that there is a problem in Script X, when the problem is that it validly calls Script Y, and Script Y is the one that actually has the problem.  The "Impacted" list is more about where you have to go to fix the issue.

The total number of occurrences of issues is on the first line of the Broken References section of the report card.  That number should be equal to the sum of the items on the Broken References query node.  If I were talking to a customer, I would either quote them that first number form the report card, or I would quote the sum of the other lines on the report card.  So either "here are the number of issues", or "here are the number of FileMaker objects that are objectively broken in some manner".