Missing or Empty Data
On this page
7.5 Missing or Empty Data
Distinguish read failure, legitimate zero results, interface hiding, and JOIN exclusion. Do not reimport the whole population because the grid is empty.
7.5.1 Effective SQL and User Scope
Group SQL overrides main SQL when defined, so different counts can be correct. Record user/layout/target and have the designer test the effective query under the same identity. Do not remove WHERE or borrow broad identities as a permanent fix. If main SQL finds a person but group SQL does not, inspect authorized ownership/conditions and change only through approved policy publication.
7.5.2 Search, Filters, and Groups
Record search/filter/group/count, then clear one condition at a time inside the permitted scope. Inspect sort/scroll, focus versus checks, refresh completion, and errors. Clearing interface conditions cannot exceed group SQL. If still empty, inspect read/query results rather than resetting view layouts repeatedly.
Figure 7.5-1. Show one fictitious person's search/filter/group changes, clearing entries, and counts. Stay within the demonstration role; do not imply all users should see an administrator's full database.
7.5.3 Relationships, NULLs, and Repeated People
INNER JOIN can exclude a person with no matching card, organization, or photo. Designers must verify keys/direction and business meaning, not indiscriminately replace all joins. Example: DEMO-017 exists but has no related photo row; validate that condition, then add the legitimate relation or adjust the approved query, not create another person.
Repeated rows can represent several cards/photos from one-to-many relationships. They do not necessarily mean duplicate master people; deleting related history to remove displayed duplication can damage data.
Figure 7.5-2. Prepare DEMO-017 in an isolated database showing master presence, missing photo relation, and query result. Label the join; never remove production photos to create the example.
7.5.4 Saved Changes Not Visible
Confirm normal submission and any validation/save messages. In-memory fields/photos are not durable results. Refresh/search by unique identifier; changing category/status may move the person outside current scope. Authorized staff should verify storage rather than adding again. Across stations compare actual databases/releases/scopes and refresh. Personal view restoration does not recover records.
7.5.5 Reconcile Samples and Counts
Test an expected-visible person, an expected-excluded person, and one with a photo, checking IDs/fields/permissions. For example, 100 master rows, 30 authorized rows, and 12 filtered rows can all be correct. A Department A user should not gain B after clearing search. If differences remain unexplained, preserve conditions and pause export/deletion/batch printing until query and display are understood.