Hardcoded column index broke save

• A factory-floor data grid showed about a dozen operator-entered columns and was saved hundreds of times per shift.
• The save function read column 4 by hard-coded index.
• A column was inserted on the left, shifting every column right by one, so index 4 now held different data.
• Saves kept writing index 4, persisting wrong values.
• Root cause: the code assumed a static layout and used positional indexing instead of stable field identifiers.
• Fix: bind the save to a stable field key, not a positional column index.

// BUG: positional index breaks when columns shift
String qty = row[5];                 // what is column 5 today?

// FIX: address columns by name, not position
String qty = row.get("QTY");         // survives column reorder / insert

• ·We had a data grid on the factory floor with about a dozen columns, saved hundreds of times a shift.
• ·The save was wired to column 4 by a hard-coded index.
• ·Someone reorganized the layout and added a column on the left, so everything shifted right by one.
• ·The save kept reading index 4, which was now a different field, so it persisted wrong values.
• ·Nobody caught it until the saved numbers stopped matching what operators had typed. The fix was to bind the save to a stable field key instead of the position.

• Reference columns by stable field keys, never by numeric position.
• Add a validation check that detects position-to-field mismatches before deployment.
• Treat any UI layout change as a trigger to re-test the save/persist path end to end.