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.
Try it here, free
SyteLine Change Request Form Template
A change control form for SyteLine configuration, customization, patch and integration changes with impact analysis and rollback plan.
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.
Run "what touches coitem" against your own database in a SyteRay evaluation.