---
title: SYSPRO e.net Business Objects vs Direct SQL for Data Extraction
slug: syspro-enet-business-objects-or-direct-sql-extraction
date: 2026-10-26
author: Nachi Raman
categories: [SYSPRO, ERP, Migration Guide]
excerpt: "Direct SQL is the fastest way to extract data from SYSPRO. e.net business objects suit real-time integration, not bulk migration. Here's when to use each."
tldr: "For migration-scale extraction, direct SQL against SYSPRO's SQL Server company database is faster and more complete. It reads every table, including the custom form plus tables, in bulk. e.net query business objects return one key or a range per call and suit integration, not bulk extraction. On Syspro Cloud ERP, the read-only OData service is the only route."
canonical: https://clonepartner.com/blog/syspro-enet-business-objects-or-direct-sql-extraction
---

# SYSPRO e.net Business Objects vs Direct SQL for Data Extraction


**Direct SQL is the fastest and most complete way to extract data from SYSPRO.** e.net query business objects return XML for a single key or a range of items per call. They are designed for transactional integration, not bulk extraction. If you need to pull thousands of customers, inventory records, sales orders, and GL transactions out of SYSPRO for a migration, direct SQL against the company database is the right tool. Business objects have a role, but it is a narrow one.

This distinction matters now more than ever. SYSPRO's formal notice confirms that the Initial License Fee and Annual License Fee model is being discontinued, with existing licences valid until **31 October 2026** (outside the U.S.) or **31 December 2026** (U.S.) ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)). Teams evaluating a platform exit need to understand exactly what each extraction path can and cannot do — before the clock runs out.

For teams already planning a target platform, see our [SYSPRO to Dynamics 365 Business Central Migration Guide](https://clonepartner.com/blog/blog/syspro-to-dynamics-365-business-central-migration-guide) for a full object-by-object mapping.

## What Are SYSPRO e.net Business Objects?

**SYSPRO e.net business objects are XML-based programmatic interfaces to SYSPRO's business logic.** They accept XML input, execute against the database, and return XML output. Each business object name is exactly six characters: three for the module, one for the object type, and a two-character mnemonic ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/business-objects/business-objects-ovr.htm)). Business objects are called by name — they are executable components, not URL paths.

The object types relevant to data extraction and integration:

- **Query (`Q`)** — Read-only. Returns data without modifying the database. Examples: `ARSQRY` (Customer Query), `INVQRY` (Inventory Query), `SORQRY` (Sales Order Query), `BOMQRY` (BOM Costing Query).
- **Setup (`S`)** — Creates, modifies, or deletes master data. Examples: `ARSSCS` (AR Customer Maintenance), `INVSST` (Inventory Stock Code Maintenance), `APSSSP` (AP Supplier Maintenance), `INVSWH` (Inventory Warehouse Maintenance).
- **Transaction (`T`)** — Posts transactional data. Examples: `SORTOI` (SO Sales Order Import), `PORTOI` (PO Purchase Order Import), `APSTIN` (AP Invoice Posting), `INVTMB` (Inventory Bin Transfers), `WIPTJR` (WIP Job Receipts).

For data extraction, only Query objects matter. Setup and Transaction objects write to SYSPRO — they are the loading mechanism, not the extraction mechanism. If you are integrating a third-party application with SYSPRO, these write objects ensure data enters the system correctly. e.net is not SOAP-only. The SYSPRO 8 e.net Communications Load Balancer hosts a REST binding (`portRestHttp`) alongside its net.tcp, basic HTTP and WS-HTTP bindings ([help.syspro.com](https://help.syspro.com/syspro-8-2026-r1/topics/syspro-services/syspro-8-enet-communications-load-balancer/syspro-8-enet-communications-load-balancer.htm)).

### Why e.net Business Objects Are Poor for Bulk Extraction

Query business objects return data for **a single key or a range of items per call** ([help.syspro.com](https://help.syspro.com/syspro-8-2023/resources/pdfs/2023-release/technical/syspro-8-best-practices-for-connecting-to-syspro.pdf)). Every call runs the same business rules, aggregation and calculations as the rest of SYSPRO, including tax, ageing, currency conversions and discounting. That is valuable for real-time integration — a web storefront checking a customer's credit status, for instance — but devastating for migration-scale extraction.

The practical constraints:

- **Many round-trips.** A full table means many calls, each passing through the business logic layer.
- **XML overhead.** Every response is wrapped in XML. For a table like `InvMaster`, the payload per record is larger than the equivalent SQL result set.
- **No arbitrary joins.** Each query object returns the shape SYSPRO designed for it. To combine data the object does not return together, you make separate calls and stitch the results in your own code. In SQL, you write the join.
- **Archived data gaps.** SYSPRO notes that `SORQRY` cannot query archived sales orders ([help.syspro.com](https://help.syspro.com/business-object-library/G_Objects/sor/sorqry/sorqry.htm)). Direct SQL cannot reach them either. SYSPRO's archiving copies purged sales orders, jobs and bills of materials to XML files outside the live tables ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/ovr-archiving.htm), SYSPRO 7 Update 1 help). Collect those files separately. Our guide on [archiving SYSPRO history](https://clonepartner.com/blog/blog/how-to-archive-syspro-history-before-switching-erp) covers this.

> [!WARNING]
> **Harmony is not an API.** SYSPRO Harmony is a collaborative social platform inside the ERP, not a REST wrapper or data access layer ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/harmony/harmony-ovr.htm)). Do not confuse it with e.net or OData.

## How Does Direct SQL Extraction Work in SYSPRO?

**SYSPRO 8 stores all data in Microsoft SQL Server.** The architecture separates system configuration from transactional data. Each SYSPRO company gets its own database, and a single system-wide database stores cross-company configuration. A site with one operating company therefore has two databases ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)).

Direct SQL means connecting to SQL Server with a read-only account and running `SELECT` queries against the company database tables. No XML, no business logic layer, no per-record round-trips.

```sql
-- Read the customer master and its custom form table in full
SELECT * FROM ArCustomer;
SELECT * FROM [ArCustomer+];
```

Each query returns the whole table in one round-trip. Through `ARSQRY`, you would request customers by key or range and parse the XML that comes back.

SYSPRO's own integration guidance warns against connecting to its databases directly with SQL drivers, because this "will invariably affect performance, solution availability, service levels and licensing" ([help.syspro.com](https://help.syspro.com/syspro-8-2023/resources/pdfs/2023-release/technical/syspro-8-best-practices-for-connecting-to-syspro.pdf)). That warning targets permanent integrations. For a one-time migration extract, use a read-only account, run the heavy queries outside working hours, and agree the approach with your SYSPRO partner.

SYSPRO tables follow a module-prefix naming convention with a maximum of 18 characters per table name ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). The core tables for a standard extraction are below. Our [SYSPRO SQL table map](https://clonepartner.com/blog/blog/syspro-sql-table-map-for-migration) covers them in more detail.

**Financial and General Ledger**
- `GenMaster` / `GenTransaction`: GL chart of accounts and journal entries
- `TblCurrency` / `TblCurrDatedRates`: Currencies and dated exchange rates
- `ApBank`: Banks

**Accounts Receivable and Payable**
- `ArCustomer` / `ArCustomerGroup`: Customer master and groups
- `ArInvoice`: Customer invoice history
- `ApSupplier`: Supplier master
- `ApInvoice`: Supplier invoices

**Inventory and Manufacturing**
- `InvMaster` / `InvWarehouse`: Stock codes and warehouse-level inventory
- `InvMovements`: Inventory movements
- `InvSerialHead` / `LotDetail`: Serial numbers and lot traceability
- `BomOperations` / `BomWorkCentre`: Routing operations and work centres

**Sales and Purchase Orders**
- `SorMaster` / `SorDetail`: Sales order headers and lines
- `PorMasterHdr` / `PorMasterDetail`: Purchase order headers and lines

**Work in Progress**
- `WipMaster`: WIP jobs
- `WipJobAllMat` / `WipJobAllLab`: Materials and labour allocated to jobs

Direct SQL extraction requires careful handling of referential integrity. Moving sales order history from `SorMaster` and `SorDetail` requires that the corresponding customer records in `ArCustomer` and stock codes in `InvMaster` have already been extracted and mapped to the target system.

### The Custom Form "Plus Tables" Problem

SYSPRO stores custom form data in separate tables suffixed with `+`. SYSPRO's database guide says custom form data for the customer table `ArCustomer` "is stored in a table named 'ArCustomer+'" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)). The fields in these tables are defined by each site, so no two SYSPRO installations have the same plus-table columns.

This means:

- Your extraction script must discover the plus table structure at runtime using `INFORMATION_SCHEMA.COLUMNS`.
- The `+` character in table names requires square-bracket escaping in SQL: `SELECT * FROM [ArCustomer+]` ([help.syspro.com](https://help.syspro.com/syspro-8-2024/resources/pdfs/syspro-8-database-architecture-technical-guide.pdf)).
- Some query business objects can return custom form fields. `ARSQRY`, `INVQRY` and `SORQRY` each have an `IncludeCustomForms` option, which defaults to No ([help.syspro.com](https://help.syspro.com/business-object-library/G_Objects/sor/sorqry/sorqry.htm)). They still return one key or range per call, and only for the forms that object covers.
- The OData service can query plus tables. It lists them with the company as a suffix instead of the `+`, for example `ApSupplier+` in SQL Server appears as `ApSupplier_edu1` in OData ([help.syspro.com](https://help.syspro.com/syspro-8-2025/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)).

If your SYSPRO instance uses custom forms, direct SQL is the most complete extraction path, because it reads every plus table in bulk. Our post on [migrating SYSPRO custom form fields](https://clonepartner.com/blog/blog/syspro-custom-form-fields-migrating-plus-tables) covers the mapping side.

## e.net Business Objects vs Direct SQL: Head-to-Head

| Criteria | e.net Business Objects (Query) | Direct SQL |
|---|---|---|
| **Data scope** | Filtered set per call, per object | All tables, all columns, full joins |
| **Custom form fields** | Some objects, with `IncludeCustomForms` set | Full access via plus tables |
| **Archived data** | Not reached (e.g. archived sales orders) | Not reached. Archives sit in XML files |
| **Throughput** | One key or range per call | Bulk `SELECT` across whole tables |
| **Response format** | XML | Native SQL result set (tabular) |
| **Business logic** | Applies SYSPRO calculations (tax, ageing, currency conversion) | Raw data — you handle transformations |
| **Write capability** | Yes (Setup/Transaction objects) | Read-only recommended |
| **Cloud ERP access** | Not for data access. SYSPRO names OData as the only route | No — blocked on SYSPRO Cloud ERP |
| **Infrastructure** | Requires e.net Communications Load Balancer | SQL Server connection string |

**The one scenario where business objects win for reads:** if you need SYSPRO's calculated values — tax, ageing, currency conversions, discounting — applied to the output, query objects do that work for you ([help.syspro.com](https://help.syspro.com/syspro-8-2023/resources/pdfs/2023-release/technical/syspro-8-best-practices-for-connecting-to-syspro.pdf)). For raw data extraction at scale, SQL wins on every other axis.

## What About SYSPRO OData and Business Activity Queries?

Two other extraction paths sit between direct SQL and e.net business objects. Both have legitimate use cases.

### Business Activity Queries (BAQs)

**SYSPRO Business Activity Queries are SQL views created in the company database.** SYSPRO says "any SQL user with db_datareader permissions can retrieve data using the views" ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/insights-and-reporting/business-activity-queries/business-activity-queries-ovr.htm)). BAQs are useful when you want a governed, pre-joined dataset — for instance, a view that denormalizes WIP jobs with their materials and labour allocations — without writing raw multi-table joins yourself.

BAQs can include custom form fields ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/insights-and-reporting/business-activity-queries/business-activity-queries-ovr.htm)). Once published, you can read them with direct SQL, and SYSPRO says they "can also be surfaced in OData" ([help.syspro.com](https://help.syspro.com/syspro-8-2023/resources/pdfs/2023-release/technical/syspro-8-best-practices-for-connecting-to-syspro.pdf)). SYSPRO documents no row limit for BAQs.

> [!TIP]
> The **Business Activity Query Export** program moves query *definitions* between SYSPRO environments. It does not export data ([help.syspro.com](https://help.syspro.com/syspro-8-2025/g_programs/imp/impvwe/impvwe.htm)). Don't confuse the two.

### SYSPRO OData Service

SYSPRO's OData service provides **read-only access, based on OData 4.0 standards,** to the company and system databases ([help.syspro.com](https://help.syspro.com/syspro-8-2024/topics/syspro-services/syspro-odata-service/syspro-odata-service.htm)). It supports `$filter`, `$select`, `$top`, `$skip` and first-level `$expand`. SYSPRO's own example expands `InvMaster` into its related `InvWarehouse` rows in a single call (same source).

Each call returns at most 5,000 rows. SYSPRO says: "we limit to 5000 rows under the Microsoft best practice guidelines for performance and fair use" ([help.syspro.com](https://help.syspro.com/syspro-8-2025/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)). Large tables need paging with `$top` and `$skip`.

OData is the right path when:

- You are on **SYSPRO Cloud ERP** and direct SQL is not available. SYSPRO states this is the only mechanism available when applications need access to SYSPRO data in the Cloud ERP environment ([help.syspro.com](https://help.syspro.com/syspro-8-2025/topics/insights-and-reporting/syspro-odata/syspro-odata.htm)).
- You need to feed data into Power BI, Tableau, or Excel without writing SQL.
- Your extraction is a scheduled, incremental sync rather than a bulk one-time pull.

For a full bulk migration of an on-premise SYSPRO instance, OData adds network overhead and pagination latency that direct SQL avoids entirely.

### Report Writer

SYSPRO's built-in Report Writer can send a report to an ASCII file, and data "can also be exported to third party software such as spreadsheets" ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/_repovr.htm)). This is a manual, UI-driven process that is error-prone for full database extraction. The Data Definition Export feature exports table definitions from the Report Writer Data Dictionary, not the data itself ([help.syspro.com](https://help.syspro.com/syspro-7-update-1/reppz4.htm)).

## How Does the 2026 Licensing Change Affect Data Extraction?

For teams evaluating a platform exit, the timeline is often dictated by SYSPRO's licensing change. On 15 July 2026, SYSPRO published a formal notice ending the Initial and Annual Licence Fee model.

Existing licences expire on **31 October 2026** for customers outside the U.S. and **31 December 2026** for U.S. customers. The notice dates what happens next "from your expiry date": 1 November 2026 outside the U.S. and 1 January 2027 in the U.S. From then, a new subscription agreement is needed to keep using SYSPRO ([syspro.com](https://www.syspro.com/formal-notice-change-to-syspro-licensing/)).

The formal notice explicitly addresses data ownership: "On cessation of your current licence, you have the right to export your data." SYSPRO also states that they "will provide a straightforward process for this on request."

What the notice does **not** specify:

- Whether the system enters a read-only mode after licence expiry.
- How long the export process remains available.
- Whether e.net, OData, and direct SQL access continue post-expiry.

**Extract your data while your licence is active and your SQL Server access is unambiguous.** Relying on an undefined post-expiry export process introduces risk to your financial records and compliance data. Waiting until after expiry to discover what "a straightforward process" means is a gamble you don't need to take.

For broader context on separating the data migration from the ERP implementation project, see [ERP Data Migration vs Implementation: What's the Difference?](https://clonepartner.com/blog/blog/erp-data-migration-vs-implementation-whats-the-difference).

## Structuring a SYSPRO Data Extraction Project

Regardless of which extraction path you choose, the workflow follows a predictable sequence:

1. **Inventory your schema.** Query `INFORMATION_SCHEMA.TABLES` and `INFORMATION_SCHEMA.COLUMNS` against the company database. Identify the system-wide database and each company database. Discover all plus tables. Document which tables contain active data vs. empty shells.
2. **Define the migration scope.** Not everything needs to move. Open orders, active customers, current inventory, and the GL chart of accounts are almost always in scope. Years of closed sales order history may not be — but ask your auditor or legal team how long it must be kept first. Our guide on [what data you should actually migrate](https://clonepartner.com/blog/blog/what-data-should-you-actually-migrate-to-your-new-erp) covers this decision in detail.
3. **Extract via SQL, transform in staging.** Pull raw data into a staging database using `SELECT INTO` or bulk export to JSON. Apply field-level mapping and transformation in staging, not in production queries. For SYSPRO Cloud ERP where SQL access is blocked, use the OData service instead.
4. **Validate before loading.** Record-count parity between source and staging. Checksum verification on financial totals. Referential integrity checks — every `SorDetail` row must reference a valid `SorMaster` header. Serial and lot traceability data (`InvSerialHead`, `LotDetail`) carries compliance obligations and must be validated with no orphaned records.

> [!NOTE]
> **Two clocks.** The data extraction and migration is measured in days — most migrations complete within 1–5 business days, depending on data volume, complexity, and API rate limits on the target system. Small datasets (under 10,000 records) can finish in under 24 hours. The broader ERP implementation (selecting, configuring, redesigning business processes, and training users) is a separate project measured in months. ClonePartner does not implement ERPs. Your implementation partner or the ERP vendor does that.

## When to Use Each Method

**Use direct SQL when:**
- You are on-premise with SQL Server access.
- You need custom form (plus table) data.
- You need WIP history or lot traceability data from the live tables.
- You are performing a one-time bulk extraction for migration.

**Use e.net Query business objects when:**
- You are building a real-time integration (not a migration) that needs SYSPRO's calculated values (tax, ageing, currency conversions).
- You need a single record or small filtered set, not a bulk extract.
- You want SYSPRO's business rules applied to the output rather than raw table data.

**Use OData when:**
- You are on SYSPRO Cloud ERP and have no SQL access.
- You need a read-only feed for BI or analytics tools, within the 5,000-row limit per call.
- You want to query published BAQs over HTTP.

For most teams planning a SYSPRO exit in 2026, the answer is direct SQL, supplemented by BAQs for denormalized views and OData only when cloud constraints demand it. Business objects are for integration, not extraction.

## How ClonePartner Handles SYSPRO Data Extraction

We prefer direct SQL for SYSPRO extraction. SYSPRO's SQL Server foundation means direct database access is the fastest and most complete path. A dedicated migration engineer owns the project end to end: discovering the plus-table schema, writing the extraction queries, mapping fields to the target platform, and running multi-stage validation with checksums, record-count parity, and referential integrity checks.

We move SYSPRO data into the ERP you choose, for example [Business Central](https://clonepartner.com/blog/migrate/syspro-to-microsoft-dynamics-365-business-central), [NetSuite](https://clonepartner.com/blog/migrate/syspro-to-oracle-netsuite) or [Acumatica](https://clonepartner.com/blog/migrate/syspro-to-acumatica). We handle the extraction, mapping, and validation so your team can focus on the ERP implementation.

Pricing is one fixed price per project, starting at $500 ([clonepartner.com](https://clonepartner.com/pricing)). It scales with data volume, custom fields, attachment size and the platforms involved. No hourly billing, no per-record metering. Every project includes unlimited sample migrations before the full run.

For related reading, see [In-House vs. Outsourced Data Migration](https://clonepartner.com/blog/blog/in-house-vs-outsourced-data-migration).

> Planning a SYSPRO data extraction before your 2026 licence expiry? Book a free 30-minute scoping call and get a fixed-price proposal — no hourly billing, no surprises.
>
> [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Should I use SYSPRO e.net business objects or direct SQL for data extraction?

Direct SQL is the better choice for bulk data extraction and migration. It reads every table in the company database, supports multi-table joins, and reaches all custom form plus tables in one pass. Query business objects return data for a single key or a range of items per call, so they suit integration, not bulk extraction.

### Can SYSPRO e.net business objects extract custom form data?

Some can. Query objects such as ARSQRY, INVQRY and SORQRY have an IncludeCustomForms option, which is off by default. They return custom form fields one record or range at a time. Custom form data lives in separate plus tables, such as [ArCustomer+]. Direct SQL reads every plus table in bulk, and the OData service exposes them with a company suffix.

### How do I extract data from SYSPRO Cloud ERP?

For SYSPRO Cloud ERP environments where direct SQL access is blocked, the SYSPRO OData Service is the only supported mechanism. It provides read-only access based on OData 4.0 standards, and SYSPRO limits it to 5,000 rows per call, so large tables need paging with $top and $skip.

### Can I still extract data from SYSPRO after my licence expires in 2026?

Licences expire on 31 October 2026 outside the US and 31 December 2026 in the US. SYSPRO's formal notice states you have the right to export your data on cessation of your licence and that SYSPRO will provide a straightforward process on request. However, the notice does not specify whether SQL, OData, or e.net access continues post-expiry. Extract your data while your licence is active.

### Is SYSPRO Harmony an API for data extraction?

No. SYSPRO Harmony is a collaborative social platform inside the ERP that connects users via a chat method. It is not an API, a REST wrapper, or a data extraction tool.