------------------------------
Martin Pistora
------------------------------

I am returning with this question, as I still need an answer.

We have version 9.1.10 here, which I haven't had a chance to test yet. But the description https://www.ibm.com/docs/en/datacap/9.1.10?topic=variables-select hasn't changed.

Root Cause

The SELECT variable in Datacap is architecturally designed as a single-field dropdown - the flist multi-field population is a LOOKUP-only capability. The documentation note saying SELECT supports it is misleading/incomplete; in practice, the secondary field write-back via flist does not fire with SELECT in Navigator.

Working Solutions (Ranked by Fit)

Option 1 - Hybrid: SELECT for display + LOOKUP hidden trigger (Recommended)

Use SELECT on the visible vendor name field for the clean dropdown UX, then place a hidden LOOKUP variable on a second invisible field (Vendor_Number) that auto-triggers when the first field changes:

<!-- On Vendor field - clean dropdown, single column shown -->
<SQL dsn="*/lookupdb:cs">
  SELECT VendorName FROM VendorTable WHERE VendorName LIKE '@@Vendor@@%'
</SQL>

<!-- On Vendor_Number field - hidden field, auto-resolved via LOOKUP -->
<SQL flist='Vendor_Number' dsn="*/lookupdb:cs">
  SELECT VendorID FROM VendorTable WHERE VendorName = '@@Vendor@@'
</SQL>

Set Vendor_Number field visibility to hidden in the page definition. When the operator selects from the SELECT dropdown, the LOOKUP on the hidden field fires automatically via field dependency and writes VendorID silently.

Option 2 - Stay on LOOKUP but suppress unwanted columns via SQL aliasing

Instead of fighting SELECT, keep LOOKUP and control what the operator sees by aliasing the ID column to an empty or non-visible label, and using DisplayColumns configuration to restrict the results grid:

<SQL flist='Vendor,Vendor_Number' dsn="*/lookupdb:cs">
  SELECT VendorName AS "Vendor Name", VendorID AS " " 
  FROM VendorTable 
  WHERE VendorName LIKE '@@Vendor@@%'
</SQL>

Then in the field's Lookup property, set DisplayColumns=VendorName only - the VendorID column still maps via flist position but is visually suppressed in the results window.

Option 3 - DICT variable with a custom SQL-backed dictionary

Pre-populate a dictionary file at batch-open time using a custom RuleRunner script that queries your SQL, then use DICT which natively supports displayed value vs stored value:

' Build dict: display=VendorName, stored=VendorID
DC.BuildDictionaryFromSQL "VendorDict", _
    "SELECT VendorName, VendorID FROM VendorTable", _
    "*/lookupdb:cs"

Then bind the field as DICT type pointing to VendorDict. The VendorID is stored silently while VendorName is shown - exactly the DICT display/store split you described.

Option 4 - Stored Procedure / View to flatten the need

Create a SQL view that returns only the display column but embeds the ID into the VendorName string in a parseable way, then strip it post-selection via a FixUp script. Least elegant but works without any Datacap config change.

Recommendation

Go with Option 1 for minimal configuration change - it gives you the clean SELECT single-column dropdown the operator sees, while the hidden LOOKUP silently resolves Vendor_Number in the background. This is the closest equivalent to the DICT displayed-vs-stored pattern, without needing dictionary maintenance.