Skip to content

Update an application error's deleted flag

clsAppError exposes soft-delete semantics through its public DeletedFlag property rather than the BOF hard-delete lifecycle. Setting DeletedFlag on an already-persisted object marks it dirty; the subsequent Save() routes to the update path and executes UpdateSQL. A structurally separate hard-delete lifecycle also exists on the class but has no executable delete SQL and no functioning result handling.

Field Value
Operation ID OP-LV-03
Trigger Caller changes clsAppError.DeletedFlag on an object retrieved via GetAppError and calls Save()
Inputs Existing clsAppError object (with AppErrorSeqNum from a prior retrieve), new DeletedFlag value
Outputs Update request executed against App_Error; no rows-affected validation performed for this path
Primary components clsAppError.DeletedFlag (property setter), clsAppError.Criteria.UpdateSQL
Entry point Application\SAIF.Application.LogView\clsAppError.vb

Steps

  1. Change the flag. The caller sets DeletedFlag on a previously retrieved (marked-old) clsAppError instance. The setter compares the new value to the current value and calls MarkDirty() only when they differ, which is what makes the object eligible for the update lifecycle on Save().
  2. Save the object. Because the object was loaded via Load()/MarkOld() (see Retrieve a single application error) and is now dirty rather than new, the BOF save lifecycle routes to the update path instead of insert.
  3. Execute the update. The update path runs MyCriteria.UpdateSQL (SQL-009, App_Error), which is built as: 
    Update App_Error Set Deleted_Flag = @DeletedFlag,  Where App_Error.App_Error_Seq_Num = @AppErrorSeqNum
  4. On failure: this class defines no AfterUpdate override, so there is no InsertError-style rows-affected check on this path; success or failure of the update is not surfaced back to the object's message collection.*

Process flow

The following diagram visualizes the deleted-flag update flow, including why the statement text itself is a known defect.

flowchart TD
    Start([Caller sets DeletedFlag<br>on existing clsAppError]) --> Dirty[Property setter compares value,<br>calls MarkDirty if changed]
    Dirty --> Save[Caller calls Save]
    Save --> Update[Update lifecycle runs UpdateSQL]
    Update --> Text{Statement text has<br>trailing comma before WHERE}
    Text -->|Yes| Risk([Statement may fail or<br>behave unpredictably at execution])

Failure and edge-case behavior

  • clsAppError.Criteria.UpdateSQL builds the literal text "Update App_Error Set Deleted_Flag = @DeletedFlag, Where App_Error.App_Error_Seq_Num = @AppErrorSeqNum" — the trailing comma immediately before Where makes this statement invalid as written against standard SQL Server T-SQL syntax; callers should treat this update path as broken until the statement is corrected.
  • No AfterUpdate override exists on clsAppError, so unlike inserts (BR-006), a failed or zero-row update does not add an error message to the object — the caller has no BOF-level signal that the update did not take effect.*
  • A structurally separate hard-delete lifecycle exists (BeforeDelete binds @AppErrorSeqNum against MyCriteria.DeleteSQL), but DeleteSQL is also a blank placeholder and the entire AfterDelete result-handling body is commented out, so invoking a true Delete() on this object has no functional row-count validation and no confirmed executable delete SQL.*

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

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