Cross Check Engine

This are just some notes re how I might re-write how CCMDB.accdb runs the cross checks. It is a long-term goal to do this, but it’s not trivial to implement and would require re-building the way we do cross-checks, which would take several days and likely lead to other disruptions.

See also Problems related to event timing of data consistency checks and CCMDB.accdb flickers or flashes.

Definition/Data structure

• table CCE_CrossChecks
  • fields: Error msg string, wiki URL, query name, soft/hard check, complete/incomplete, start_DtTm, end_DtTm
• table CCE_Fields
  • fields: database field name, form field name, associated checkbox (can there ever be more than one?), tmpField (YN) (Need to be able to do cross checks on tmp entries, but they need to work totally differenty in terms of how they are triggered)
• table CCE_FieldChecks
  • relates CCE_Fields to CCE_CrossChecks

• need a way to validate these tables against the wiki

Methods

complete checks

• check_checkbox_crosschecks (checkboxName):
  • when a checkbox is checked, this runs all associated checks via check_runCheckPatID()
• check_field_crosschecks (fieldName):
  • when a field is changed, this runs all associated checks via check_runCheckPatID()
    • it might be better to track which fields are being changed somehow and only run these checks on the attempt to close the record; if it is run when the field is edited then a check based on two fields would always create an error until the second one is entered. Could this be based on closing the form instead? But on closing, how would one know which fields were edited?
• check_runCheckPatID(crossCheck)
  • the actual check runner: runs the query; if error it displays the error details and, if hard check, unchecks any related checkboxes (based on the fields that are involved); provides button to open the query for further info but doesn't open automatically

pre-sent checking

• check_incompletes ()
  • pre-send checker needs to run all checks flagged as incomplete;
    • this really should not find anything since these would also trigger when initially entered; do we actually need it?
• check_runCheckAll(crossCheck)
  • runs the query; if there are any profiles with errors, it displays error details and query with actual errors

Actions

• Data_Integrity_Check - When an error is found, launch an error window that gives the error, a link to the wiki page, a button to open the query
• Is it possible to leave that window open and let the user figure out the problem? OR does it need to close? I think turning it not modal would allow moving back and forth.
  • If it stays open, what should happen if the user edits a field or checks a checkbox while still open? No good answer, so should stay modal.

Other thoughts

• Wiki pages contain the info; drawing from there is too slow, though

• Would it be best to store the query as text rather than as query? It would facilitate dumping the actual query to the wiki, if we wanted to do that. It would also facilitate text manipulation of the query... but harder to work with since one can't just use the query builder. And yet, easier to work with since one can actually annotate the query with comments.

• Is complete vs incomplete the right way to think of this? A field may not be mandatory to enter early at all, but once it's triggered by a field edit, shouldn't it be correct? I suppose it might not be if a check looks at two fields... but that is also a different issue that would always crop up when checking based on fields. And it would mean a field triggered check doesn't even make sense for anything other than incomplete fields? So maybe there needs to be a "profile closing" trigger that checks incomplete records, and no field trigger at all?

_dev_CCMDB implement better cross-check triggering

added: 2022-04-27 action: 2022-04-27

• Cargo

• Categories