IFS Cloud: How to Extract Data Directly From a Table

How to extract IFS Cloud data safely

1. 1Decide whether you truly need SQL. If the data is already exposed by a projection (OData), use that; it applies security and business logic for you.
2. 2Find the entity in the application first: the page you see in Aurena maps to a logical unit (LU), which maps to a view named after the LU and a _TAB base table.
3. 3Prefer the LU view (for example the CUSTOMER_ORDER_LINE view) over the CUSTOMER_ORDER_LINE_TAB table. Views translate stored codes into client values and include some derived columns.
4. 4If you are customer-hosted, ask the DBA for a dedicated read-only schema or user with SELECT granted on the needed views, not on the application owner schema.
5. 5Run extracts against a replica, standby or off-peak window; large scans on the production database slow online users.
6. 6For incremental loads, pick a reliable change column (a rowversion or modified-date column on the table) and test that it changes on every update.
7. 7For managed cloud, use projections or the vendor's supported data and analytics feed instead of asking for database credentials.
8. 8Document every extract: source view, filters, schedule, owner. Re-test after each IFS update because view definitions can change.

Supported options in order of preference

-- Read-only extract from a view (customer-hosted only; schema name varies)
SELECT order_no, line_no, catalog_no, buy_qty_due
FROM   customer_order_line
WHERE  rowversion > :last_extract_ts;

Common pitfalls

• !Writing to _TAB tables directly; it bypasses validation and can corrupt dependent state.
• !Reading the application owner schema with a shared admin account instead of a dedicated read-only user.
• !Building incremental loads on a column that is not updated by every code path.
• !Large full-table scans on the production database during working hours.
• !Forgetting that a managed cloud contract may forbid direct database access altogether.