Developer ToolsFree generatorPDF, Excel, Word exportInfor SyteLine

SyteLine Custom Table CREATE Script Generator (with Standard Columns)

Custom SyteLine tables follow a set of conventions: a site_ref column, a business key, a RowPointer GUID and standard audit columns. This generator builds a CREATE TABLE script with those pieces already in place, so a developer starts from the right shape instead of copying an old table.

Fill in

Generated code
Download:

Table script

-- Custom table following SyteLine conventions. Test in a development database first.
CREATE TABLE dbo.ue_tool_crib_log_mst (
  site_ref nvarchar(8) NOT NULL,
  log_id nvarchar(30) NOT NULL,
  tool_id nvarchar(30) NOT NULL,
  issued_to nvarchar(30) NULL,
  issue_date datetime NULL,
  qty decimal(19,8) NOT NULL DEFAULT 0,
  NoteExistsFlag tinyint NOT NULL DEFAULT 0,
  RecordDate datetime NOT NULL DEFAULT GETDATE(),
  RowPointer uniqueidentifier NOT NULL DEFAULT NEWID(),
  CreatedBy nvarchar(128) NOT NULL DEFAULT SUSER_SNAME(),
  UpdatedBy nvarchar(128) NOT NULL DEFAULT SUSER_SNAME(),
  CreateDate datetime NOT NULL DEFAULT GETDATE(),
  InWorkflow tinyint NOT NULL DEFAULT 0,
  CONSTRAINT PK_ue_tool_crib_log_mst PRIMARY KEY CLUSTERED (site_ref, log_id)
);
GO

CREATE UNIQUE NONCLUSTERED INDEX IX_ue_tool_crib_log_mst_RowPointer
  ON dbo.ue_tool_crib_log_mst (RowPointer);
GO

Smoke test

-- Insert and read back one row, then roll back
BEGIN TRAN;
INSERT INTO dbo.ue_tool_crib_log_mst (site_ref, log_id) VALUES (N'DEFAULT', N'TEST-001');
SELECT TOP (5) * FROM dbo.ue_tool_crib_log_mst;
ROLLBACK TRAN;

Custom tables in production SyteLine should be registered and exposed through the supported extension mechanism for your release (table definition, IDO and forms) so that upgrades and the framework see them. Treat this script as a starting point for development, adjust data types to match your standards, and remove or edit the smoke test key type if your key is not text.

Want a map of your SyteLine customizations?

An optional review that lists custom tables, IDOs, forms and event handlers, and flags those most likely to need work in an upgrade.

Optional. The tool and every export work without this. No spam.

How to use the generator

Enter a table name without the _mst suffix, choose the key column and type, and paste your additional columns. Each extra line should end with a comma because the standard columns follow. Copy the result into SSMS on a development database. After the table exists, register it in the framework so that an IDO and forms can use it, following the extension guidance for your release.

  • Prefix custom objects consistently to avoid collisions with Infor tables
  • Keep site_ref at the front of the primary key
  • Keep RowPointer unique, since the framework uses it to identify rows

Why the standard columns matter

RowPointer lets the framework and IDO layer address a specific row regardless of the business key, and it is also how notes and attachments link to records. site_ref supports multi-site isolation, and the audit columns support who and when reporting. A table missing these columns may work in SQL but will behave unpredictably in forms, workflows and notes.

Common mistakes

Teams often create tables directly in production, name them without a custom prefix and forget the site_ref column. Others skip documenting the table, so the next upgrade team has no idea what it feeds. Keep a short design record for each custom table: purpose, owner, related IDO, forms and any integration that writes to it.

  • Create in dev, promote through a controlled change
  • Record owner and purpose for each custom table
  • Include custom tables in the upgrade regression test

Frequently Asked Questions

Can I just create a table in SQL and use it in SyteLine?

The table will exist, but forms and IDOs only see it once it is defined through the framework's extension process. Use the supported method for your release so that the table survives upgrades and respects security.

What is RowPointer used for?

RowPointer is a unique identifier for each row. The framework uses it to find a specific record, to attach notes and to link related data. Every custom table should have it, with a unique index.

Should the table name end in _mst?

Standard multi-site tables use the _mst suffix, with a site-aware view in front. Follow the pattern your release and customization guidelines specify, and keep custom names clearly separate from Infor names.

Can I change the data types of the audit columns?

You can, but matching the types used in standard tables reduces surprises with tools and the framework. Check an existing table in your own database and mirror it.

If you have a growing set of custom tables and extensions, Netray can help inventory them and prepare a documented upgrade impact list.