Wayfinder / Case study / Topic detail

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