Configuring Ignition Form Input for SQL Database Entry

In Ignition 7.8.4, the three editable HTML inputs inside a Label can display text entry, but they do not provide a direct Ignition component-property path for saving those values to SQL. Choose the data-entry path based on whether the target is a Vision client screen or a web page, then submit values through a route that explicitly handles them.

Choose the data-entry path for the target screen

First identify what “Ignition page” means in this project. The correct implementation depends on whether users enter data in a Vision client or in a web-facing page.

For a Vision client, use native text-entry components and a button event script. For a web page, use WebDev rather than attempting to read the Label’s HTML controls as Vision component properties. In either case, the SQL write must receive the submitted values explicitly.

Why the Label form does not expose its values

The example contains three unnamed text inputs inside a plain <form>. It has no submit control, form action, method, field names, or Ignition event that transfers browser-entered values into an Ignition property or script variable. A user can type into the rendered controls, but that alone does not create the data path needed for a database write.

HTML controls and Ignition components are different objects. A Vision text field has a component property that a Vision event script can read. An HTML input rendered within a Label remains part of the rendered HTML; it is not automatically the equivalent of a sibling Vision Text Field. To use browser HTML as a form, provide a submission path and a server-side handler that accepts and processes named values. The shown snippet does not do that.

Prepare a Vision-native input screen

Use this path only when the target is a Vision client screen. Before scripting, give each text-entry component a stable component name, configure the project’s database connection, and identify the destination table and columns.

1. Set up the inputs. Add a Vision text-entry component for each value and name the components fname and lname for the two-field example below. Confirm each component displays the value entered in the client before proceeding.
2. Set up the submit action. Add a button and place the database-write script in its action event. Confirm the event is attached to that button and that the two component names match the names used by the script.
3. Set up the destination mapping. Replace the example table and column names with the actual database identifiers. Confirm that the number and order of SQL columns match the number and order of question-mark parameters.

Keep validation specific to the application’s input rules. At minimum, decide whether empty values are permitted and check required fields before running the insert. A rejected or incomplete form should not be treated as a successful database submission.

Insert Vision input with matching SQL parameters

The example below corrects two inconsistencies in the supplied script: it reads the last name from lname, not fname, and it maps two columns to two placeholders and two values. Use the actual destination table and column names in the project.

fname = event.source.parent.getComponent('fname').text
lname = event.source.parent.getComponent('lname').text

system.db.runPrepUpdate(
    "INSERT INTO yourdatabase (fname, lname) VALUES (?, ?)",
    [fname, lname]
)

getComponent must resolve the named components from the button’s parent container; adjust the component lookup if the screen hierarchy differs. The prepared statement keeps the values separate from the SQL text. Do not concatenate user-entered strings into the SQL statement.

The original sample listed three columns—fname, lnameolor, and colornum—but supplied only two placeholders and two values. That mapping is incomplete. If the actual insert requires three columns, provide three placeholders and three values in the same order, and read the third value from its corresponding input. Confirm the target database’s column names and types before changing the insert.

Route a browser form through WebDev

For a web page, use the WebDev module route identified for this use case. A browser form needs named fields and an explicit submission target; a WebDev handler then needs to accept those submitted fields and perform the database operation. The Label markup by itself supplies none of these pieces.

1. Confirm the page context. Verify that users access a web page, not a Vision client screen. If it is a Vision screen, stop this route and use native Vision components.
2. Define submitted fields. Give each browser input a field name that corresponds to a value the handler expects. Confirm the rendered page still accepts input and that each field has a distinct name.
3. Configure form submission. Set the form to submit to the WebDev endpoint and configure that endpoint to handle the submitted values. Confirm a test submission reaches the handler before adding the database write.
4. Write and verify the database operation. Pass the received values as parameters to a prepared insert whose columns, placeholders, and values match. Confirm the handler reports or records success only after the insert completes.

The available example does not specify WebDev endpoint names, request-processing code, or database configuration. Read those details from the project’s installed Ignition 7.8.4 WebDev setup rather than copying an assumed endpoint or API.

Diagnose missing or incorrect database values

Change one layer at a time: confirm input values first, then confirm the handler or event receives them, and finally confirm the database insert. This isolates a missing UI-to-script path from a SQL mapping or database-target problem.

Verify the stored row before release

1. Enter distinctive test values in every field and confirm the values appear in the intended Vision components or arrive at the WebDev handler.
2. Submit once and confirm the event or handler completes without a database error. If the application exposes an insert result or error, inspect it rather than assuming that a click means success.
3. Read the corresponding row from the configured destination table and compare each stored column with the submitted test value. Confirm the last-name field did not receive the first-name value and that every intended column has a matching parameter.

Ignition form and SQL FAQ