Clear Cutover Get a quote

Data and SQL

How to find the SQL table and column behind any SyteLine form field

By Al Hasib Tamim, published 24 October 2026

Applies to: SyteLine 8, 9 and 10. The SQL and trace methods need on-premises SQL Server access. Form and IDO methods also work in cloud, subject to permissions

Short answer

Every field on a SyteLine form is bound to a property of an IDO collection, and most IDO properties map to a column in an _mst table. Open the form in Design Mode, check the field's binding and the form's collection to get the IDO and property name, then look that IDO up on the IDOs form to see the table and column behind it. If you have SQL access, you can also search the database's column list by name, or trace the query the form runs when it loads. Some fields are derived, calculated rather than stored, and those you trace through the IDO's definition instead of a table.

Method 1: Follow the IDO (works everywhere)

This is the most reliable route, because it follows exactly what the form uses.

  1. Open the form and switch on Design Mode (you need design permissions, so use a test environment).
  2. Select the field and open its component properties. The binding shows the property name it's bound to, for example DueDate.
  3. Check the form's collection to find which IDO that property belongs to, for example SLCoitems.
  4. Open the IDOs form, find that IDO, and look at its properties and tables. The property's entry shows whether it's bound to a table column, and which one. The IDO's table list shows which _mst tables it reads and how they're joined.

Now you know, for example, that "Due Date" on the order line form is due_date in coitem_mst.

Exact form and tab names vary a little between versions, but the chain is always the same: field → property → IDO → table and column.

Method 2: Search the columns (on-premises)

If you know roughly what the column might be called, ask SQL Server directly. On a test copy or with a read-only login:

SELECT  TABLE_NAME,
        COLUMN_NAME,
        DATA_TYPE,
        CHARACTER_MAXIMUM_LENGTH
FROM    INFORMATION_SCHEMA.COLUMNS
WHERE   COLUMN_NAME LIKE '%bin%'          -- your guess
  AND   TABLE_NAME  LIKE '%[_]mst'        -- base tables only
ORDER BY TABLE_NAME, COLUMN_NAME;

This works well for distinctive names. For common words like stat, qty or date, you'll get hundreds of hits, so Method 1 or 3 is faster.

To confirm a candidate, find a record you can see on the form and check that the column holds the same value:

SELECT co_num, co_line, due_date
FROM   coitem_mst
WHERE  site_ref = 'MAIN' AND co_num = 'YOURORDER';

Method 3: Trace the form (on-premises, last resort)

When a form is heavily customized or the binding isn't clear:

  1. In a test environment, start a short Extended Events session (or SQL Server Profiler on older setups) filtered to the SyteLine database and your test user's login.
  2. Open the form and load one record.
  3. Stop the trace and read the statements. You'll see the queries, or the stored procedures, the IDO ran to fill the form.

Keep traces short and filtered, and never leave one running on production.

Derived fields: when there's no column

Some fields are calculated, not stored, for example totals, flags, or values pulled from another record. In SyteLine these are typically derived or unbound IDO properties, filled by an expression, a method or the form itself.

If Method 1 shows a property with no table column behind it:

  • Look at the property's definition in the IDO for its expression or source.
  • Check the form's events and scripts for anything that sets the field.
  • Check custom IDO methods if the IDO has an extension.

For a report, it's often easier to recreate the calculation in SQL from the underlying columns, and document how you did it.

The same chain works for integrations

The IDO and property names you find in Method 1 are exactly what the IDO REST API uses, so this is also how you find what to ask for in an integration. See Connecting external systems with the IDO REST API.

Common surprises

  • The customer's name isn't in customer_mst. It's in custaddr_mst, with cust_seq = 0.
  • Order lines are per release. coitem_mst has a row per line and release, which matters for totals.
  • Views without _mst return nothing in SSMS without a site context. Query the _mst table with site_ref.
  • The same label means different things on different forms. Always check the binding rather than trusting the caption.

More table details are in the SyteLine SQL table cheat sheet.

FAQ

How do I find which table a SyteLine field is in?

In Design Mode, get the field's bound property and the form's IDO, then look up that IDO on the IDOs form to see the table and column.

Can I search the SyteLine database for a column name?

Yes, on-premises: query INFORMATION_SCHEMA.COLUMNS with a LIKE filter, ideally limited to tables ending in _mst.

Why can't I find a SyteLine field in any table?

It's probably a derived property, calculated by the IDO or the form rather than stored. Check the property's definition and the form's events.

Do I need Design Mode permissions?

Yes, to view the bindings. Use a test environment and ask your administrator if you don't have them.

Systems I work on