---
title: Update an application error's deleted flag
summary: Persists a change to an existing App_Error row's Deleted_Flag through the BOF update lifecycle.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Application.LogView
reference_type: package
operation_id: OP-LV-03
trigger: Caller sets DeletedFlag on an existing (previously retrieved) clsAppError and calls Save()
---

# 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](error-retrieval.md)) 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](../sql/SQL-009-saif-application-logview.md), [App_Error](../database-tables.md#app_error)), which is built as:
   ```
   Update App_Error Set Deleted_Flag = @DeletedFlag,  Where App_Error.App_Error_Seq_Num = @AppErrorSeqNum
   ```
   - 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.

```mermaid
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](../business-rules.md#br-006-inserts-must-affect-exactly-one-row)), 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.*

## Related documentation
- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

> **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`