Data-entry applications
A form generated directly from a database table may be technically correct and still be difficult or unsafe to use. Real data entry often spans related records, calculated defaults, permissions, validation rules, and several changes that must succeed or fail together.
PHPRunner and ASPRunner.NET can generate the starting pages, but a useful form comes from modeling the user’s task rather than placing one input beside every database column.
Quick answer: Design each form around one business transaction. Show the context required to make the decision, ask only for information the user can supply, derive everything else, validate the complete operation on the server, and save related changes as one reliable unit.
An order-entry form is not simply an editable version of an orders table. The user may need to select a customer, see account status, add several products, apply current prices, choose a valid delivery method, review the total, and confirm that the order is within an approval limit. The final save may create an order header, multiple order lines, a status history entry, and an audit record.
Begin by writing the business action as a sentence: “Create an order for this customer,” “Check out this item to this employee,” or “Approve this expense.” That sentence defines the form more reliably than the table name does.
| Form responsibility | What the user should experience | What the application should handle |
|---|---|---|
| Identify related records | Choose a customer, product, employee, or location by a familiar name | Store the correct key and prevent invalid relationships |
| Provide context | See status, availability, balance, price, or policy information beside the decision | Read the authoritative values without making them editable |
| Collect the transaction | Enter the few values that cannot be derived | Calculate defaults, owners, dates, totals, and initial status |
| Protect the data | Receive a clear explanation when the operation cannot proceed | Recheck permissions, concurrency, and complete business rules on the server |
| Complete the save | Receive one success result for the whole action | Commit every dependent change together or roll all of them back |
Every editable field creates work and another opportunity for error. A reliable form distinguishes between information the user knows, information the application can derive, and information the user needs only for context.
Use lookups for related records instead of asking users to type database keys. Set predictable defaults such as the current date, signed-in employee, starting status, or business unit. Display calculated totals and reference information without turning them into ordinary inputs. Hide technical columns that exist for synchronization, auditing, locking, or internal processing.
Defaults must remain visible when they affect the outcome. Automatically assigning an owner is helpful; assigning the wrong owner invisibly is not. Let the user confirm or change a derived value when the business process requires judgment.
Required-field indicators, input formats, dependent choices, and immediate messages help the user correct simple problems without submitting the form repeatedly.
Recheck permissions, values, relationships, totals, and workflow rules after submission. Browser checks can be bypassed and may be based on data that has already changed.
Keys, foreign keys, uniqueness, and other rules that must remain true for every writer belong in database constraints or controlled database operations.
The same rule may appear in more than one layer for different reasons. A browser can warn that an end date precedes a start date, while the server remains responsible for rejecting the save. The duplication is deliberate: one layer improves the experience and the other protects the data.
Many business forms change more than one row. An order has line items. An equipment checkout changes the checkout record and the item’s availability. An approval may update the request, append history, and create a notification.
If the third change fails after the first two succeed, the application can leave the database in a state that no user intended. Use a database transaction or an existing stored procedure so every dependent change commits together. If any required step fails, roll back the complete operation and return a message that explains what the user can do next.
Also plan for two people editing the same record. A form should detect that the underlying data changed after it was opened instead of silently overwriting the newer work. Depending on the process, the application can reject the stale save, reload the latest values, or ask the user to reconcile the differences.
Preventing every mistake is unrealistic. Decide how an authorized user corrects a wrong value, who may reverse a completed operation, and which changes require an explanation. For important records, preserve who made the change, when it occurred, and the relevant before-and-after values.
Permissions should follow the transaction. A user may be allowed to create a request but not approve it, edit a draft but not a completed record, or update only records assigned to their department. Hiding a button improves clarity, but the server must still enforce the permission when the request is submitted directly.
Both products create Add, Edit, View, and List pages from existing SQL databases and recognize common relationships. Page Designer lets developers organize fields, explanatory text, tabs, sections, and buttons around the task. Lookup settings, dependent controls, master-detail pages, and calculated values reduce unnecessary input.
Validation settings provide immediate checks, while application events provide places for server-side rules, multi-record operations, notifications, and integrations. User groups, record-level security, field permissions, and audit features help control who can perform each part of the process.
Start with one transaction that currently causes mistakes or manual cleanup. Build the complete form, test successful and rejected submissions, simulate two users changing the same record, and verify that a failed dependent update leaves no partial data behind.