SyteLine Impact Analysis: Answering "What Breaks If I Change This?"
The most expensive question in SyteLine maintenance is asked before every change and answered rigorously almost never: what else touches this? A column addition, a procedure modification, a customization retirement, each carries a blast radius defined by everything that reads, writes, or calls the thing being changed. At the scale of a real installation, thousands of procedures over thousands of tables, answering by inspection is not feasible, so teams answer by instinct and pay for the misses.
Why Manual Impact Tracing Fails
The naive method, full-text search the procedure bodies for the table name, fails three ways. It misses dynamic SQL, where the table name is assembled at runtime. It misses transitivity: procedure A never mentions your table but calls B, which writes it, so changing the table breaks A's behavior. And it drowns in noise: hundreds of hits with no indication of which read, which write, and which merely pass through. Reviews built on grep produce confidence, not knowledge.
The Resolved Call Graph Method
Reliable impact analysis requires parsing every procedure into its reads, writes, calls, and parameters, then resolving the call graph so effects propagate: if A calls B and B writes the table, A effectively writes it. SyteRay runs this analysis as part of its installation crawl. On its reference deployment, 8,636 procedures, the transitive resolution escalated 799 procedures to write-classified that show no direct data modification of their own, precisely the ones a manual review clears incorrectly. Dynamic SQL is flagged explicitly rather than silently missed, and a 100-procedure stratified audit of the classification found zero errors.
- Which procedures read this table? A query over the catalog.
- Which write it, directly or through nested calls? Same query, transitive closure included.
- Which use dynamic SQL and need human eyes? Explicitly flagged.
- What does this procedure actually touch, end to end? Its resolved effect set.
Impact Analysis as Standard Practice
Once the catalog exists and stays refreshed, impact analysis stops being a project and becomes a habit: every change request starts with a ten-second query instead of a day of tracing. Estimates lose their fear padding, code reviews focus on the genuinely ambiguous cases, and upgrade planning proceeds from an inventory of what is actually connected to what. The archaeology does not disappear because someone did it heroically; it disappears because it became infrastructure.
Frequently Asked Questions
How do I find every stored procedure that uses a SyteLine table?
Text search over procedure definitions is the common approach and it is unreliable: it misses dynamic SQL and transitive effects through nested calls. A parsed, call-graph-resolved catalog, which SyteRay builds automatically, answers it precisely, distinguishing reads from writes and direct from inherited effects.
What is transitive effect analysis?
Propagating effects through the call graph: if procedure A calls procedure B, and B writes a table, then A effectively writes that table too. On SyteRay's reference deployment, 799 of 8,636 procedures were escalated to write-classified only through this analysis.
How long does it take to build a procedure catalog for SyteLine?
It is automated. SyteRay's crawl of the reference deployment's 8,636 procedures completes in roughly 45 minutes and scales linearly with catalog size, then refreshes as the database changes.
Key Takeaways
- 1Why Manual Impact Tracing Fails: The naive method, full-text search the procedure bodies for the table name, fails three ways. It misses dynamic SQL, where the table name is assembled at runtime.
- 2The Resolved Call Graph Method: Reliable impact analysis requires parsing every procedure into its reads, writes, calls, and parameters, then resolving the call graph so effects propagate: if A calls B and B writes the table, A effectively writes it. SyteRay runs this analysis as part of its installation crawl.
- 3Impact Analysis as Standard Practice: Once the catalog exists and stays refreshed, impact analysis stops being a project and becomes a habit: every change request starts with a ten-second query instead of a day of tracing. Estimates lose their fear padding, code reviews focus on the genuinely ambiguous cases, and upgrade planning proceeds from an inventory of what is actually connected to what.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
SyteLine Customization Technical Debt Scorer
Measure how much upgrade drag, risk, and maintenance cost your SyteLine customizations have accumulated, and learn where to pay it down first.
Free ToolSyteLine MRP Health Check
Diagnose why your SyteLine MRP output is noisy or ignored, scoring data accuracy, parameters, and planner behavior across ten dimensions.
Free ToolSyteLine Consultant Cost Benchmarker
Benchmark what your SyteLine consulting engagement should cost by role, engagement model, staffing mix, and duration against current market rates.
Run "what touches coitem" against your own database in a SyteRay evaluation.
Related Resources
SyteLine Stored Procedures: How They Work and How to Analyze Them
How stored procedures run SyteLine under the hood, why call graphs make them risky to change, and how automated effect classification maps thousands of procedures safely.
Infor SyteLineSyteLine Developer Productivity: Removing the Archaeology Tax
Where SyteLine developer and consultant hours really go, schema archaeology and impact tracing, and the tooling that removes it: live schema indexes, classified procedure catalogs, governed SQL.
Infor SyteLineSyteLine Data Dictionary: Tables, Columns, and Keeping It Current
What a SyteLine data dictionary should contain, why the Infor DataMap alone is not enough, and how to build a living dictionary of your actual CloudSuite Industrial database.