Skip to content

Retrieve a single application error

clsAppError.GetAppError retrieves one error record by its sequence number through the standard BOF single-object retrieve lifecycle. The library provides no application-layer criteria filtering beyond the key — result-count validation happens entirely in AfterRetrieve.

Field Value
Operation ID OP-LV-02
Trigger Caller calls clsAppError.GetAppError(inDataportal, inAppErrorSeqNum)
Inputs IDataPortalInfo, AppErrorSeqNum
Outputs Populated clsAppError object on success; an unhandled ApplicationException("Invalid Results") when the row count is not exactly one
Primary components clsAppError.GetAppError, clsAppError.BeforeRetrieve, clsAppError.AfterRetrieve
Entry point Application\SAIF.Application.LogView\clsAppError.vb

Steps

  1. Build criteria and dispatch the retrieve. GetAppError constructs a clsAppError.Criteria(inDataportal, inAppErrorSeqNum) and calls inDataportal.DataAccessLayer.RetrieveObject(...), which drives the BOF retrieve lifecycle.
  2. Configure the retrieve request (BeforeRetrieve). A data request is built with SQLStatement = MyCriteria.RetrieveSQL and the parameter @AppErrorSeqNum bound from the criteria's AppErrorSeqNum, targeting App_Error. The single-object RetrieveSQL property on clsAppError.Criteria is a blank (single-space) string in source — there is no executable single-object SELECT statement defined in this library, so the actual retrieval SQL is not documented here.**
  3. Evaluate the result (AfterRetrieve).
  4. If the result set contains exactly one row: call Fill(Results(0)) to populate every field (DeletedFlag, AppErrorSeqNum, AppName, Environment, ErrorDate, ErrorInfo, ErrorSource, MachineName, PageName, StateInfo, UserName) from the row, then MarkOld() (BR-005).
    • On failure: throw ApplicationException("Invalid Results"). This is an unhandled exception, not a broken-rule collection entry, so the caller must catch it explicitly.
  5. Return the populated object. AfterRetrieve returns Me, which the BOF pipeline surfaces back through GetAppError as the retrieved clsAppError.

Process flow

The following diagram visualizes the single-object retrieve-and-validate flow.

flowchart TD
    Start([Caller calls GetAppError]) --> Build[Build Criteria with AppErrorSeqNum]
    Build --> Retrieve[BeforeRetrieve: bind @AppErrorSeqNum]
    Retrieve --> Exec[Execute retrieve request]
    Exec --> Count{Result count = 1?}
    Count -->|Yes| Fill[Fill object fields, MarkOld]
    Count -->|No| Throw([Throw ApplicationException<br>Invalid Results])
    Fill --> Done([Populated clsAppError returned])

Failure and edge-case behavior

  • The single-object RetrieveSQL in clsAppError.Criteria is a blank placeholder string, so this retrieve path has no documented executable SQL text in this library; the underlying query behavior cannot be confirmed from source.**
  • A zero-row match (no such AppErrorSeqNum) and a multi-row match are both treated identically as an ApplicationException("Invalid Results") (BR-005) — the exception message does not distinguish the two cases.
  • Because the exception is thrown rather than returned as a broken rule, callers must wrap GetAppError in exception handling rather than checking IsValid.*

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • Application\SAIF.Application.LogView\clsAppError.vb