PL/SQL and the Logical Unit translated into X++

The statement-by-statement translation from PL/SQL to X++ — SELECT INTO and cursors to select firstonly and while select, BULK COLLECT/FORALL to set-based DML, COMMIT/ROLLBACK/SAVEPOINT to ttsbegin/ttscommit with no partial rollback, the company column to DataAreaId and RecId, and the Logical Unit's New__/Modify__/Check_Insert___ method model to table methods and Chain of Command.

What you will be able to do

• Translate PL/SQL SELECT INTO, cursor, BULK COLLECT, FORALL and MERGE statements into their X++ equivalents
• Explain why ttsbegin/ttscommit reference counting means there is no partial rollback and no savepoint in X++
• Account for DataAreaId injection and RecId surrogate keys when porting IFS company-scoped logic
• Rewrite an LU Check_Insert___/Unpack_Check_Insert___ validation as a Chain of Command extension on validateWrite
• Identify what must actually be learned in X++ object orientation rather than assumed from PL/SQL packages

Introduction

Chapter 1 was about a rule and the architecture it produces: you cannot modify the base, so you learn to read it and wrap it. This chapter is about the day job underneath that rule — the statements you actually type.

The select family, bulk operations, and the construct map

Three surface differences, and nothing else. firstonly plays the role of a single-row fetch. Equality is == and conjunction is &&, because X++ borrows C-family operators. Fields are read through a table buffer — a variable declared with the table's type — using dot notation, rather than into separate local variables named after each…

Transactions: ttsbegin, ttscommit, and the vanishing savepoint

Read as a rename of COMMIT, this looks harmless. It is not, and this is the most consequential semantic difference in the whole language.

Company scoping and the surrogate key

Most transactional tables in D365 are company-scoped, and the AOS adds WHERE DataAreaId = <current company> to every query against them. Conceptually this is IFS's company column.

The Logical Unit method model becomes table methods and Chain of Command

An IFS LU's public write surface lives in the _API package: New__ to insert, Modify__ to update, Remove__ to delete, with Check_Insert___, Prepare_Insert___ and Unpack_Check_Insert___ as the validation and defaulting hooks that fire underneath them.

Object orientation: packages are not classes

This is the part of the chapter that is easiest to under-estimate, because the syntax makes it look optional. It is not.

Collections, temporary tables, and what replaces PL/SQL memory structures

X++ has no associative array, no VARRAY, and no Global Temporary Table in the Oracle sense. Five structures share that work instead:

Views, projections, and data entities

An IFS database view, and the _RPI/projection layer built on top of it, plays two roles at once: a joined read model for reporting, and the shape exposed to Aurena and IFS Connect for integration. In D365 that responsibility splits:

Worked translation: the same validation, twice

In IFS, this is a Check_Insert___ override in the LU's _API package, calling super() first:

Knowledge check

Summary

X++ is a SQL-embedded, table-centric ERP language, exactly like PL/SQL in spirit — the set-based instinct, the strong typing, and the habit of thinking in statements rather than row-by-row loops all transfer intact. What changes is everything that follows from logic no longer living inside the database.