Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

Return to: 4. Journeys and State Machines — topic detail

Customer record

Lifecycle: Customer record

The documented customer deletion rule is conditional: confirmation is required, and deletion is blocked when active orders exist. The evidence does not show the customer-delete controller, query, callback, or persistence code, so this remains a documented rule rather than a runtime-confirmed transition. E0004 E0006

Lifecycle: Customer record

A customer begins as an unselected or NULL current record. Add input either aborts before insertion or inserts a new row and obtains a generated customer number. Find selects a current customer for later update, deletion, or order entry. Update writes modified fields to the matching row and restores the stored row on input abort. Delete requires confirmation and is blocked when matching orders exist. These are customer-record behaviors; order and report states remain separate business-object scopes. E0007

Lifecycle: Customer record

Customer addition collects customer number, name, company, address, city, state, ZIP code, and telephone through an input object in the Java target. When input is not interrupted, the program inserts the row, obtains the last serial number, stores it as the customer number, and displays that number. The original 4GL customer addition similarly collects form input, assigns the generated identifier from SQLCA.SQLERRD[2], inserts the row, and reports that the row was added. E0009

Customer deletion is constrained by related orders. The 4GL implementation blocks deletion when matching orders exist and otherwise asks for confirmation before issuing the delete. The Java implementation likewise prevents deletion when the customer has counted orders and requires y or Y. However, the 4GL del_cust() path reportedly clears the form and displays Record deleted. after the confirmation block regardless of whether the user answered affirmatively. A negative response can therefore leave the database row intact while presenting deletion-success feedback. E0010

The source also identifies a missing area of explicit error handling for customer insertion in the overall assessment. The supplied analysis treats this as an actionable issue, although the detailed excerpts establish the insertion flow more clearly than the complete error behavior. E0008