Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.
Return to: 02 — Business Capability Map — topic detail
Customer management
In this document
Capability: Customer management
The customer module provides implemented paths for creating, locating, browsing, updating, and deleting customer records. Customer creation collects input and inserts a record into the customer table. Customer queries support navigation through results, including first, previous, next, last, select, and quit actions. Customer updates issue an update against the selected customer number. The module also provides help and state selection functions. E0001 E0002
Customer deletion is conditional. Before removing a customer, the implementation counts related rows in the orders table and blocks deletion when the count is nonzero. The user-facing message says that the customer has active orders, but the reported query counts all orders for that customer rather than demonstrably filtering for open, unpaid, or otherwise active orders. This may be a defect or may reflect an undocumented convention in the database schema; the supplied evidence does not resolve the distinction. E0002
The help material describes deletion as requiring confirmation and preserving referential integrity, and it states that customers with active orders cannot be removed. That documentation is consistent with the implemented deletion guard at a high level, but it does not resolve whether the implementation’s count of all orders has the same meaning as “active orders.” E0003 E0002
Capability: Customer management
The customer capability is implemented in the Informix-4GL source as a menu-driven workflow. The customer function opens and displays the customer form with MAGENTA attributes, draws three boxes, initializes the current customer number to NULL, and presents commands for adding one customer, adding multiple customers, finding, updating, deleting, or leaving the customer menu. Customer help maps active fields to help identifiers 1001 through 1010. E0007
Customer entry uses INPUT BY NAME and supports field help through F1 or CTRL-F. F2 or CTRL-Y sets the interrupt flag and leaves input without inserting. A normal completion inserts the customer record, obtains the generated number from SQLCA.SQLERRD[2], displays that number, and returns TRUE. The source does not show an explicit status check after the INSERT, so the effect of an insert failure remains a credible but unverified error-handling concern. The supplied evidence also does not show transaction management around customer creation. E0007 E0008
The many-add workflow repeats customer input and returns to the beginning of the form after each entry. CTRL-Y returns to the CUSTOMER menu when there are no more customers to add. The help text says that customer entry can also be committed with ESC or aborted with the INTERRUPT key, usually DEL or CTRL-C. E0007
Customer search constructs a query-by-example condition with CONSTRUCT, prepares an ordered query by last name, and browses results with first, last, next, previous, select, and quit actions. The help describes literal criteria, ranges separated by a colon, lists separated by a vertical bar, relational operators, and question-mark or asterisk wildcards. The source dynamically assembles a SELECT statement from the generated condition; the evidence does not establish whether CONSTRUCT safely escapes every possible expression, so this should not be treated as equivalent to parameterized SQL. E0007 E0008
Updating requires a selected customer number. The workflow accepts modified fields without defaults, updates the matching row, and restores the stored row if input is aborted. Deletion requires a selected customer, checks for matching orders, refuses deletion when orders exist, prompts for confirmation, and deletes only when the response is y or Y. The help states that deletion cannot be restored and is disallowed for customers with active orders. E0007
The state-help workflow first checks whether the entered state code exists uniquely. If it does not, it opens the state-list form, displays the state array, assigns the selected state code, and redisplays it. The presence and runtime consistency of the referenced state-list form are not established by the supplied evidence. E0007 E0008
Harten documentation of the Informix 4GL and Java source repository, from the retained 17 October 2026 export. The exact upstream revision analysed is not established. Source findings do not establish runtime behaviour or equivalence between the implementations.
Evidence identifiers are retained for traceability. The underlying analysis records are not included in this public edition; credential values are redacted. About this case study.