Skip to content

Update claim

Once a claim exists, subsequent edits are persisted through the update lifecycle. This operation binds every mutable claim-header field, enforces optimistic concurrency against the row's UpdateNum, and — because a claim can transition into New status after its first save — re-runs the same auxiliary-row cascade used by Insert claim whenever the current status is New.

Field Value
Operation ID OP-CE-03
Trigger Save() invoked on a claim object where IsNew = False and IsDirty = True
Inputs Modified claim header fields, ClaimID, current UpdateNum
Outputs Updated CL_INJURY_CLAIM row with UpdateNum incremented; conditional auxiliary rows for New-status claims; UpdateError broken rule on concurrency conflict
Primary components clsClaimEntry.BeforeUpdate, clsClaimEntry.AfterUpdate, clsClaimEntry.AddNewStatusData
Entry point Business\SAIF.Business.Claim.Entry\clsClaimEntry.vb

Steps

  1. Apply New-status defaulting. If ClaimStatusCode = "N" (New) at the time of save, AddNewStatusData re-applies the same New-status defaults used during insert, including the active-claim flag (BR-CE-004).
  2. Bind and execute the update statement. BeforeUpdate builds parameter bindings for every mutable claim-header field plus the ClaimID/UpdateNum predicate, and issues the update against CL_INJURY_CLAIM (SQL-022, CL_INJURY_CLAIM).
  3. Enforce optimistic concurrency. The update's WHERE clause matches on both ClaimID and the caller-supplied UpdateNum; AfterUpdate inspects the rows-affected return value (BR-CE-011).
  4. If RowsAffected <> 1: add an UpdateError broken rule indicating the row was changed or deleted by another user since it was last retrieved, and do not increment UpdateNum in memory.
  5. If RowsAffected = 1: increment UpdateNum on the in-memory object to match the newly persisted value.
  6. Re-run the New-status auxiliary cascade. When ClaimStatusCode = "N", the same save cycle persists request-decision, status-activity, type-activity, MCO-eligibility, and policy-history rows exactly as in the insert path (BR-CE-013, SQL-005, SQL-006, SQL-007, SQL-008, SQL-009).
  7. Return the saved object with the updated UpdateNum, or the broken-rule collection populated with the concurrency-conflict error.

Process flow

flowchart TD
    Start([Save called on existing claim]) --> StatusCheck{ClaimStatusCode = New?}
    StatusCheck -->|Yes| NewData[Apply New-status<br>defaults]
    StatusCheck -->|No| Update[Update CL_INJURY_CLAIM<br>WHERE ClaimID and UpdateNum]
    NewData --> Update
    Update --> Rows{RowsAffected = 1?}
    Rows -->|No| Conflict([Raise UpdateError<br>broken rule])
    Rows -->|Yes| Increment[Increment UpdateNum<br>in memory]
    Increment --> HistoryCheck{ClaimStatusCode = New?}
    HistoryCheck -->|Yes| History[Persist auxiliary<br>status rows]
    HistoryCheck -->|No| Return([Return saved claim])
    History --> Return

Failure and edge-case behavior

  • A concurrent update by another session between retrieval and save produces a rows-affected value of 0, which surfaces as an UpdateError broken rule rather than a silent no-op or exception (BR-CE-011).
  • Because business-rule bodies are commented out in clsClaimEntryBusinessRules.vb, field-level validation before the update executes relies entirely on database constraints and the optimistic-concurrency check.*
  • If a claim's status is changed to New after its initial insert, the same auxiliary-row cascade runs again on every subsequent save while the status remains New, which could produce duplicate auxiliary rows if the underlying SQL does not guard against re-insertion; no such guard was found in the traced source.*

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

Sources

  • Business\SAIF.Business.Claim.Entry\clsClaimEntry.vb