Infor SyteLine

Performance Best Practices for SyteLine Form Scripts

Slow form scripts are the number one user complaint in customized SyteLine environments. A script that adds 500ms to every record navigation makes the entire application feel sluggish. Scripts that fire unnecessary IDO calls on every event handler create server-side load that affects all users. Optimizing script performance requires understanding the execution frequency of each event, minimizing server round-trips, and caching data that does not change between records.

Minimizing IDO Calls in Event Handlers

Every IDO call from a form script is a network round-trip to the IDO Runtime server. In StdObjectLoaded, which fires on every record navigation, a single IDO call adds latency that users feel immediately. Three IDO calls in StdObjectLoaded means three round-trips multiplied by every record the user navigates through. The solution is to cache reference data during StdFormLoaded (which fires once when the form opens) and use the cache during StdObjectLoaded. Only make IDO calls in StdObjectLoaded when the data is record-specific and cannot be pre-loaded.

  • Cache reference data: load warehouses, UOMs, and status codes in StdFormLoaded into script-level dictionaries
  • Pre-load lookup data: fetch all valid items for the current warehouse once, not per-record
  • Batch IDO calls: if multiple lookups are needed, combine them into a single custom IDO method call
  • Avoid redundant loads: check if data is already cached before making another LoadCollection call
  • Measure impact: log the time before and after IDO calls to quantify the performance cost

Efficient Event Handler Execution

Event handlers should execute as quickly as possible, especially StdObjectLoaded and ColumnChanged which fire frequently during normal form usage. Apply early exit patterns: check the most common conditions first and return immediately when no action is needed. Avoid string concatenation in loops (use StringBuilder). Skip expensive operations when the relevant data has not changed since the last execution. For global scripts, the form name check should be the very first line to exit immediately for irrelevant forms.

  • Early exit: if (status == lastStatus && custNum == lastCustNum) return; // skip unchanged records
  • Form filter first: if (ThisForm.Name != "SLCoItems") return; // in global scripts, exit immediately
  • Avoid unnecessary UI updates: only set Visible/ReadOnly properties when the value actually changes
  • String efficiency: use string.Format or interpolation instead of repeated concatenation
  • Conditional execution: wrap expensive logic in if blocks that check whether the relevant field changed

Profiling and Measuring Script Performance

You cannot optimize what you do not measure. Add timing instrumentation to your event handlers during development and testing. Measure the total handler execution time and the time spent in each IDO call. Establish performance budgets: StdObjectLoaded should complete in under 100ms, StdFormPreSave under 200ms, and ColumnChanged under 50ms. When handlers exceed these budgets, profile the individual operations to find the bottleneck. Tools like the SyteLine client console log, custom timing code, and SQL Profiler help pinpoint the slowest operations.

  • Timing pattern: var sw = Stopwatch.StartNew(); ... sw.Stop(); Log("Handler took " + sw.ElapsedMilliseconds + "ms")
  • Budget enforcement: StdObjectLoaded < 100ms, ColumnChanged < 50ms, StdFormPreSave < 200ms
  • SQL Profiler: correlate slow form navigation with specific SQL queries generated by script IDO calls
  • User perception: anything over 200ms is noticeable; over 500ms is perceived as slow; over 1s is unacceptable
  • Regression tracking: log handler times to a file and review trends after each script deployment

Netray AI agents profile your SyteLine script performance, identify hot spots, and recommend targeted optimizations. Keep your SyteLine forms fast and your users productive.