SyteLine EXTGEN Stored Procedure Generator
This generator builds the skeleton of an extgen_ override for a base SyteLine 9.x or CSI 10.x stored procedure, with a change header, the base parameter list and audit queries. Use it when a base procedure needs different behaviour and no IDO event or extension point fits.
Fill in
Paste the exact base name from the Edit Stored Procedure form or sys.procedures.
Paste the parameter list exactly, same names, types, order and OUTPUT markers.
1. Override skeleton
/* =============================================================
EXTGEN override of dbo.BaseProcedureNameSp
Purpose : Block the base action when the customer is on credit hold and show the hold reason.
Author : J. Developer
Ticket : CHG-2026-114
Mode : Copy base logic and modify
Base modify_date when copied: <fill in from block 3>
============================================================= */
CREATE PROCEDURE dbo.EXTGEN_BaseProcedureNameSp (
@CoNum CoNumType
, @Infobar InfobarType OUTPUT
)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @Severity INT = 0;
-- Copy mode: paste the base body here WITHOUT its extgen redirect block,
-- then change only what the ticket requires and mark each change.
-- Replace mode: write the new logic and set every OUTPUT parameter callers expect.
-- custom logic placeholder
RETURN @Severity;
END
GO2. How the mechanism works
-- Base procedures that support extension check near the start for a procedure -- named extgen_<BaseName>. If it exists, the base runs it in place of its own logic. -- SQL Server matches the name case-insensitively under the usual case-insensitive -- collation, so EXTGEN_ and extgen_ refer to the same object. -- -- Your copy must NOT contain that redirect check, or it can call itself. -- Easiest path: Edit Stored Procedure form > select dbo.BaseProcedureNameSp > Remove To Extgen > Copy Procedure. -- That copy adds the prefix and removes the redirect code; then edit and submit it. -- The submitted code must begin with CREATE PROCEDURE. -- -- After every Infor update, open the EXTGEN Listing form: -- green = matches the base method -- yellow = base changed after your extgen: Edit Stored Procedure > Compare w/ Base, merge, resubmit -- red = no base method exists (removed or replaced by an assembly extension): -- rebuild the change as an IDO extension class.
3. Audit existing overrides
-- All overrides in this database
SELECT name, create_date, modify_date
FROM sys.procedures
WHERE name LIKE 'EXTGEN[_]%'
ORDER BY name;
-- Override vs base: which bases changed after the override was written
SELECT e.name AS extgen_proc,
e.modify_date AS extgen_modified,
b.name AS base_proc,
b.modify_date AS base_modified,
CASE WHEN b.object_id IS NULL THEN 'Base missing'
WHEN b.modify_date > e.modify_date THEN 'Base newer: review'
ELSE 'OK' END AS status
FROM sys.procedures AS e
LEFT JOIN sys.procedures AS b
ON b.name = SUBSTRING(e.name, 8, 128)
WHERE e.name LIKE 'EXTGEN[_]%'
ORDER BY status, e.name;
-- Does the base still contain the extgen redirect? (0 = not found)
SELECT CHARINDEX('EXTGEN_', UPPER(OBJECT_DEFINITION(OBJECT_ID(N'dbo.BaseProcedureNameSp')))) AS redirect_position;Based on the Mongoose and CSI 10.x documentation for extended (extgen_) stored procedures and the EXTGEN Listing form. Confirm the form names on SyteLine 9.x before relying on them. The parameter list must match the base exactly. Extgen procedures are an on-premises technique; plan to move overrides to IDO extension classes for cloud.
Extgen override inventory
We can list every extgen override in your SyteLine database, flag those whose base changed and suggest the extension-class equivalent.
Optional. The tool and every export work without this. No spam.
How to use it
Enter the exact base procedure name and paste its parameter list from the base header without changes: same names, user-defined types, order and OUTPUT markers. Describe the change, the author and ticket, and choose whether you copy and modify the base logic or replace it. The header records the base procedure's modify_date at copy time, which is what you compare against after the next update. In practice, generate the copy with the Edit Stored Procedure form (Remove To Extgen, Copy Procedure) so the redirect code is removed for you, then use this skeleton's header and structure to document it.
- One override per base procedure; keep it in source control.
- Mark every changed line with the ticket number.
- Test both the success path and every error path the base had.
Where this lives in SyteLine
Base procedures that support extension look for a procedure named extgen_ plus their own name and run it instead of their own logic when it exists. The Edit Stored Procedure form creates the copy, and the EXTGEN Listing form lists every extgen_ method with a status colour: green when it matches the base, yellow when the base was modified more recently, red when no base exists. The usual fix for a red one is to rebuild the change as an IDO extension class that does the same work. Compare w/ Base on the Edit Stored Procedure form shows the differences to merge for a yellow one.
Worked example: the audit after an update
After applying an update, run block 3. Suppose EXTGEN_ fixed three procedures: two show OK, one shows Base newer: review because Infor shipped a fix to the base after your override was written. Open that one in the EXTGEN Listing form, which shows yellow, use Compare w/ Base to see the new base code, merge Infor's fix into your copy and resubmit. If a row shows Base missing, the base was removed or moved to code, and your override no longer runs at all: rebuild the change as an extension class.
Gotchas
A parameter mismatch causes errors at call time, not when you create the procedure, so test through the form that calls the base. Copy mode freezes the base logic as of the copy date, so every later Infor fix to that procedure is missing from your system until you merge it; this is the main long-term cost of extgen. Replace mode is cleaner but you own every output parameter. Overrides are invisible to users and easy to forget, so keep a register of them with the ticket and owner.
Frequently Asked Questions
What is an extgen stored procedure in SyteLine?
It is a copy of a base Infor stored procedure with the extgen_ prefix. Base procedures that support extension check whether that copy exists and, if it does, run it instead of their own logic. It lets you change base behaviour without editing the vendor object, which an update would overwrite.
Is it EXTGEN_ or extgen_?
Infor documentation writes extgen_ in lower case. SyteLine databases normally use a case-insensitive collation, so SQL Server treats EXTGEN_ and extgen_ as the same name. Pick one style, use it consistently, and search with LIKE 'EXTGEN[_]%' so the underscore is matched literally.
What does a yellow entry on the EXTGEN Listing form mean?
The base method was modified more recently than your extgen version, usually by an Infor update. Open Edit Stored Procedure, use Compare w/ Base to see the differences, merge what you need into your copy and resubmit. Until you do, your system runs your older copy of the logic.
Should I still use extgen in new work?
Only when no IDO event, extension class or configuration option fits. Extgen is an on-premises database technique and each override needs review after every update. For new behaviour, and for anything that may move to CloudSuite Industrial, an IDO extension class is the more durable choice.
If you are planning an upgrade and want an inventory of extgen overrides and what each one would become in an extension class, we can produce that from your database on site.
Related Tools
SyteLine Custom Stored Procedure IDO Method Generator
Build a SyteLine-style stored procedure with typed parameters, @Infobar messaging and a severity return code, then test it and publish it as an IDO method.
Infor SyteLineSyteLine Upgrade Regression Test Checklist
A practical regression checklist for SyteLine upgrades across business processes, customizations, reports and integrations.
Infor SyteLineSyteLine 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.
Developer ToolsSyteLine Form Script Generator
Fill in the form, IDO, properties and target variable to get a VB form script method for SyteLine 9/10 that loads related data and shows it on the form.
More Developer Tools tools
See all- SyteLine IDO REST Request Generator
- SyteLine SQL Query Generator for Item, Job and Order Tables
- SyteLine SQL Blocking and Long Running Query Script Generator
- SyteLine Custom Table CREATE Script Generator
- SyteLine Mongoose Framework Events Reference
- SyteLine Event Action Types Reference
- SyteLine Event Action Parameter Functions Reference
- SyteLine WinStudio Standard Form Events Reference
- SyteLine Mongoose API Options Reference
Keep exploring
Free tools
- SyteLine Custom Stored Procedure IDO Method GeneratorBuild a SyteLine-style stored procedure with typed parameters, @Infobar messaging and a severity return code, then test it and publish it as an IDO method.
- SyteLine SQL User-Defined Data Types ReferenceThe SQL Server user-defined data types SyteLine uses for columns and stored procedure parameters, with scripts to read exact lengths from your own database.
- SyteLine Custom Table CREATE Script GeneratorCreates a SQL Server CREATE TABLE script for a custom SyteLine table that follows the standard column and key conventions.
Guides
- SyteLine Stored Procedures: The Hidden Engine and How to Map ItHow 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.
- SyteLine IDO Custom Property and Method CreationCreate custom IDO properties and methods in SyteLine. Property mapping, method signatures, stored procedures, and .NET method development guide.
- SyteLine Impact Analysis: Answering "What Breaks If I Change This?"How to answer the scariest SyteLine question, what breaks if I change this, with resolved procedure call graphs, transitive effect analysis, and a live schema index.