The SyteLine Data Dictionary Problem, and How SyteRay Self-Indexes Your Database
Ask a SyteLine site for its data dictionary and you will usually get one of three answers: a PDF of the Infor DataMap from whenever the system was implemented, a spreadsheet someone maintained until 2019, or a shrug and a name, the person who knows. None of those survives contact with reality, because every SyteLine database diverges from the factory schema the day customization begins: user-defined fields, site extensions, bolt-on tables, repurposed columns. SyteRay cannot work without an accurate picture of your specific database, so the first thing it does at installation is build one. This post explains how that self-indexing works, what the resulting schema pack contains, and why a living data dictionary changes more than just AI answers.
Why the Factory DataMap Is Not Enough
Infor's DataMap for CloudSuite Industrial 10 is a genuinely useful artifact: it documents the delivered schema, table by table. But it describes the product, not your installation. It does not know about your user-defined fields, your custom tables, the columns your integrator added in 2014, or which delivered tables your site actually populates versus leaves empty.
Conversely, your live schema alone is not enough either: INFORMATION_SCHEMA tells you a column exists but not what it means. The useful object is the intersection, factory semantics where they apply, live truth everywhere, and that is exactly what SyteRay compiles. The reference deployment's schema pack is built from the CSI 10.00 DataMap intersected with the customer's live schema, covering 1,970 tables with 15,784 distinct column names indexed.
What Self-Indexing Actually Does
At install time, SyteRay reads your SQL Server catalog directly: tables, columns, data types, keys, and relationships, including everything nonstandard. It layers the DataMap's semantic knowledge over the live structures it matches, and it encodes SyteLine's structural conventions, the _mst master-table naming, site_ref site scoping, and the join paths that connect the commercial core, as schema truth the query planner can rely on.
Crucially, the index does not rot. A live schema registry re-reads the database on a rolling basis, so when a column is added or a customization lands, SyteRay's picture updates without anyone remembering to maintain a document. The dictionary becomes a property of the running system rather than a project that was done once.
- Live catalog read: every table and column as it actually exists, including customizations.
- DataMap intersection: factory semantics layered over matching live structures.
- SyteLine conventions (_mst tables, site_ref scoping, core join paths) encoded explicitly.
- Rolling refresh keeps the index current as the schema evolves.
What the Schema Pack Powers
The schema pack is the foundation the rest of SyteRay stands on. Question answering grounds its SQL generation in it. The query enforcer validates every generated statement against it, which is how phantom tables and invented columns get caught before execution instead of after. The stored-procedure catalog cross-references it, so a procedure's read and write sets resolve to real tables.
Alongside the structural index, SyteRay accumulates a semantic layer of validated question-to-SQL pairs, the golden pairs, which capture how your organization's questions map onto your schema. Structure from the index, meaning from accumulated validated usage: together they are what a data dictionary always wanted to be.
A Dictionary Humans Can Use Too
Once the index exists, it stops being an internal artifact. Asking SyteRay which table holds customer order lines, what a status code means, or how jobs connect to items is asking questions against the compiled schema knowledge, with answers that reflect your database rather than a generic manual. For new developers and analysts, that turns weeks of schema archaeology into conversation.
This matters beyond convenience. Institutional schema knowledge at most SyteLine sites is concentrated in a few tenured people, and it leaves when they do. An automatically maintained, queryable index is how that knowledge becomes infrastructure, present on day one for every future hire, consultant, and tool.
Key Takeaways
- 1Static data dictionaries fail because every SyteLine database diverges from the factory schema; the useful object is the DataMap intersected with your live schema.
- 2SyteRay compiles that intersection automatically at install: 1,970 tables and 15,784 distinct columns indexed on the reference deployment.
- 3A rolling schema refresh keeps the index current, so the dictionary tracks reality instead of rotting.
- 4The same pack grounds SQL generation, powers query validation, and answers schema questions for humans.
Want a data dictionary that maintains itself? SyteRay builds one from your database during evaluation. Contact ajay@netray.co.
More Insights
From Question to Governed SQL: How SyteRay's Evidence-First Answers Work
Generic AI chatbots fail on ERP data because they guess at schemas and invent numbers. SyteRay takes a different contract: every answer over your SyteLine database ships with the SQL that produced it and the tables it read. Here is the pipeline that makes that possible.
SyteRayHow SyteRay Classifies Every SyteLine Stored Procedure's Side Effects
A mature SyteLine site runs on thousands of stored procedures that nobody fully remembers. SyteRay crawls the whole catalog, 8,636 procedures on the reference deployment, and classifies what each one reads, writes, and calls, including transitive effects. Here is how and why.
SyteRayWhy We Built Semantic Views for SyteLine: One Source of Truth for Open Orders
When two SyteLine reports disagree about how many orders are open, the root cause is almost never a bug. It is two different definitions. SyteRay's semantic layer encodes each business definition exactly once, as reviewable SQL views, and everything reads from them.