How to Review Your ACL Log

Whether you script your projects or use menu commands, you need to review your ACL log carefully.

Good analysts review their results and the log as they work in ACL, after they think they are done, and have others review their log before the ACL project is relied upon.

(You can’t imagine the dumb mistakes my team and I found that saved us a lot of embarrassment later.)

The easiest way to review the log is to export it to WordPad and review it there. For export instructions, go to the lastest verison of ACL help and search for the Exporting log entries topic.

Follow these steps to review your ACL log:

1. Search for the following phrases and ensure that when they occur, they don’t affect the logic or flow of your scripts.

   bypassed – indicates how many records did not meet the criteria of a filter, extract, or join command.

   This phrase does not always indicate a flaw in your script logic, but you want to check the number of bypassed records to ensure that it ia appropriate. Ensure the records you are bypassing should be bypassed. During script development, as a test, you might want to reverse the filter/extract/join logic to check that the same number of records are bypassed that you want to keep.

   In other words, if your filter is Amount <= 200, change the filter to Amount >= 200.

   ignored – usually this indicates that a field in your script doesn’t match any of the fields in the active table. This isn’t always fatal, but check to make sure.

   fail –  as in “Command failed”. Depending on the command, this could be an error.

   could not be found – may indicates that a script referenced a field that doesn’t exist (usually means you spelled the field name wrong).

   duplicates detected –  make sure you removed the duplicates before analyzing the population as duplicates can affect counts, percentages, and ratios.

   unable – usually means you tried to delete something and that item was not found, so it could not be deleted. Check your spelling of the item to be deleted, that the path is correct, or make sure the item exists in the first place. This does not always indicate an error.

   test – as in “test was true/false” or “0 records met the test”. Make sure the result of the test was what you were expecting.

   invalid – usually indicates an “Invalid path specified”. Check the path and your path syntax. This also occurs if you have a delete command in your script, you deleted something manually, then ran the script–which isn’t an error.

   When documenting your scripts, do not use the bolded words above; otherwise, it will take you longer to review the log. Find other words to use in your descriptions.

2. Note the counts each file/table created and make sure they are correct (correct number of records imported, joined, bypass, extracted, exported, etc.).
3. In scripts and logs, check all conditional computed fields to ensure the second line is blank.* If not, ACL will ignore the second line–which means if you put a condition in the second line (for example, see the condition in red below), ACL will ignore it, even if the data matches the condition. In other words, the value in the conditional computed field will never match any condition entered on the second line because ACL ignores that condition.
   

   *You should catch this error when you create and test the computed field and the resulting values, but it’s a good idea to check this again at the end.

   Incorrect Example (second line is NOT blank)

   DEFINE FIELD c_Name COMPUTED
     "Part-time"   IF Salary <  21000
     "Entry-Level" IF Salary >= 21000 AND Salary < 33000
     "Manager"     IF Salary >= 30000 AND Salary < 90000
     "OVERPAID"    IF Salary >= 90000
     "**Review**"

   Correct Example

   DEFINE FIELD c_Name COMPUTED
                                   <--- blank line
     "Part-time"   IF Salary <  21000
     "Entry-Level" IF Salary >= 21000 AND Salary < 33000
     "Manager"     IF Salary >= 30000 AND Salary < 90000
     "OVERPAID"    IF Salary >= 90000
     "**Review**"

4. Review your scripts to ensure each one is commented/documented and the descriptions are complete and accurate. When you copy one script to create another, make sure you make all the appropriate changes in your logic and your comments. Check the following in each script:
   – Description/purpose of script
   – Date the script was created/updated, and what was updated.
   – Critical and/or complicated operations or functions are well documented.
   – Other items per your script conventions (you do have script conventions that you follow, right?)
5. In your scripts, remove unneeded commands and leftovers entering during script development or troubleshooting, such as:
   – PAUSE
   – FIRST (as in import or join only the FIRST 10)
   – ESCAPE
   – Other unneeded lines and extra blank lines (leave some, but not 3 in a row)

What other items do you check your logs for?

Other ACL scripting articles

Advertisement