# Fixing SyteLine's 'Object reference not set to an instance of an object' error

> Source: https://netray.co/erp-help/syteline-ido-error-object-reference-not-set
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.

## Kind

error

## System

syteline

## Erp

Infor SyteLine (CloudSuite Industrial)

## Module

IDO Runtime / Mongoose

## Query

SyteLine error object reference not set to an instance of an object

## Alternate Queries

- SyteLine IDO runtime error object reference not set to an instance of an object
- CSI form crashes with NullReferenceException
- SyteLine .NET client object reference error opening form
- Mongoose IDORuntimeError object reference not set

## Applies To

SyteLine 8.x, 9.x, CloudSuite Industrial (CSI) 10.x, .NET smart client and IDO Runtime

## Steps

### Isolate and fix the null reference

**Items:**

Note exactly which form, tab or button was active when the error appeared - the error dialog's stack trace (click Details) usually names the assembly, e.g. Mongoose.IDO or a customization DLL.

If the stack trace references a custom form script (VB.NET/C# in Application Studio or Scripts folder), open that script and find the line referencing a field or DataRow - the crash is almost always a .Rows[0] or field access on an empty result set.

If it points at Mongoose.IDO or an IDO method (GetList, Load, Save), check whether a related IDO relationship or lookup was recently changed - a broken relationship returns null instead of an empty collection in some client versions.

Reproduce with IDO Data Service logging enabled (Administration > IDO Collection Editor or IDOLogging in the client config) to capture the exact IDO method and parameters that were called right before the crash.

Check Application Studio for recently modified field validation events, FormLoad, or FieldChange events on that form - a null check missing after an upgrade is the most common cause.

If the error follows a recent SyteLine patch or ESP application, compare the form's customization against the base form - patches sometimes rename or remove fields that customizations still reference.

For third-party add-ons (EDI, barcode, CRM connectors), disable the add-on's plugin/hook for that form temporarily to confirm it is the source before opening a case with the vendor.

Once the null source is found, add a null/DBNull check before the reference (If row IsNot Nothing AndAlso Not row.IsNull("field")) rather than suppressing the error, since suppressing it usually just moves the crash to the next field.

## Sections

### Why this is not a single bug

**Body:**

SyteLine's .NET smart client wraps almost every unhandled exception from a form script, IDO call, or third-party plugin in the same generic dialog, so 'object reference not set to an instance of an object' can come from dozens of unrelated causes: a customization referencing a field that no longer exists, an IDO relationship returning null instead of an empty set, a report parameter that was never populated, or a race condition where a grid tries to read a row before the IDO load finishes.

That is why the fix always starts with the stack trace, not the error text. Clicking Details (or checking the SyteLine client log, typically in the user's AppData or a configured log path) tells you which assembly threw it - Mongoose.Windows.Forms usually means a base form or grid issue, while a company-specific DLL name means a customization.

### The most common real-world causes

**Body:**

In practice the top cause is a form customization (Application Studio script or Visual Studio class library extension) that assumes a field or related IDO always has data, then breaks the first time a record is missing that data - for example a custom FieldChange handler reading Site.Warehouse.Name when the site has no default warehouse configured.

Second most common: an IDO extension or business rule DLL that was compiled against an older IDO schema. After a SyteLine upgrade or a database schema change (custom field added/removed), the compiled extension can reference a column that IDOGen no longer maps the same way, and the generated proxy method returns null where the extension expects a populated object.

Third: grid or lookup controls opened before their underlying IDO collection finished loading, common on slow SQL Server connections or after enabling additional grid columns that pull from a joined IDO - the UI thread reads Rows[0] before the async load populates it.

### Using IDO logging to pin it down fast

**Body:**

Enable IDO method call logging (via the IDO Collection Editor's logging option, or the client's IDORuntimeError trace) and reproduce the crash. The log will show the last successful IDO method call and its parameters immediately before the exception - this is the fastest way to identify whether the null is coming from data (a real missing record) or code (a bad customization).

**Code:**

- -- Check for the underlying missing/null relationship in SQL when the IDO points at a table
- SELECT * FROM co WHERE co_num = 'SO12345' AND site_ref IS NULL;
- -- SyteLine IDOs frequently null out when a foreign-key style reference (site_ref, whse_ref) has no matching parent row

## Pitfalls

Wrapping the crashing line in a blanket Try/Catch that swallows the exception - this hides real data problems (missing site, warehouse, or customer record) instead of fixing them.

Assuming it is a SyteLine bug and opening a support case before checking your own customizations - most instances trace back to a company-specific script or extension.

Not checking whether the crash is user-specific - a role-based field security setting can return null to users without access to a field, which a customization written for admins does not expect.

Ignoring the client-side log file location - without it you are debugging blind, since the on-screen dialog rarely shows the full stack.

Forgetting that IDOGen-regenerated proxy classes must match the compiled extension DLL version - a stale DLL after a database schema change is a frequent, hard-to-spot cause.

## Ai Angle

When this error is reported to Netray's ERPray grounded on a company's SyteLine instance, it can correlate the timestamp of the crash against the IDO call log, the last modified date of Application Studio customizations, and the actual table/column state in SQL Server, then point a developer straight at the specific script line and the missing data condition rather than having them grep through log files by hand.

## Faq

### Is this a bug in SyteLine itself?

**Answer:** Rarely. It is a generic .NET null reference exception that the SyteLine client happens to display for any unhandled crash, whether from base code, a customization, or a third-party plugin. Check the stack trace before assuming it is a core product bug.

### Where do I find the SyteLine client log file?

**Answer:** Location varies by install, but it is commonly under the user's AppData\Local or a configured Logs folder referenced in the client's config file. Administration > System Log or the IDO Collection Editor's logging options can also route detail there.

### Can a missing custom field cause this after an upgrade?

**Answer:** Yes. If a patch or upgrade regenerates IDOGen proxies and a custom field was renamed or dropped, any compiled extension DLL still referencing the old field name will get a null back at runtime instead of a compile error.

### Does this ever happen on a stock, uncustomized form?

**Answer:** It can, usually from a data integrity issue (an order or job referencing a site, warehouse, or customer record that was deleted directly in SQL rather than through the application), which breaks an IDO relationship the form assumes is always populated.

## Search terms

syteline object reference not set, syteline nullreferenceexception, syteline idoruntimeerror, syteline client crash form, mongoose ido error, syteline application studio null reference, csi form crash fix, syteline ido runtime error object reference

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json