The statement-by-statement translation from M3's MI-transaction, JDBC and IPA world into X++ — GetItmBasic to select firstonly, row-by-row MI update loops to update_recordset, IBM i commitment control to ttsbegin/ttscommit, CONO/DIVI to DataAreaId and RecId — and the mindset shift from calling a published API surface to owning the data layer.
What you will be able to do
Translate an MI single-record transaction, a JDBC read and an MI list transaction into their X++ equivalents
Explain why a row-by-row MI update loop is the anti-pattern update_recordset exists to remove
Describe ttsbegin/ttscommit reference counting and why there is no partial rollback
Account for CONO/DIVI's disappearance behind DataAreaId, financial dimensions and RecId when porting a query or a join
Choose between direct table access, framework methods and the data entity layer for a given extension
Introduction
Part 1 of this domain was about a wall: MI is the boundary between code outside the Business Engine and the tables it protects, and MAK was the only way through that wall that touched source.
The select family: from MI transactions and JDBC to X++
```java MIRequest request = new MIRequest("MMS200MI", "GetItmBasic"); request.addField("ITNO", itemNumber);
The critical mindset change: who is allowed to touch the table
Every M3 developer has internalised a rule: never write to the database directly — go through MI. It is good discipline, and it is easy to over-apply once you move to D365, where the instinct would say "raw table access must still be the dangerous option." It is not, and understanding why is the single most important reframe in this…
Transactions: ttsbegin, ttscommit, and no partial rollback
Read as a rename of the implicit commit that closes out an MI call, this looks harmless. It is not, and it is the most consequential semantic difference in the runtime.
CONO, DIVI and the keys that moved
M3 developers already have a strong, correct instinct here — it just attaches to different mechanics.
Extension surfaces, restated for the language you write
Part 1 covered the extension surfaces at the architecture level. Restated here, at the level of the code you actually type:
Objects, types and the missing collection classes
Classes, interfaces, inheritance, public/protected/private, static methods — X++'s object model needs an afternoon, not a course, for anyone who already writes Java. The differences are mostly cosmetic: this.field instead of this.field with more ceremony around getters, new ClassName() instead of a constructor call through a factory, and…
Worked translation: the same validation, twice
Requirement: a sales order line's requested quantity must not exceed the available (on-hand minus allocated) quantity at the shipping warehouse.
Knowledge check
Summary
X++ is a SQL-embedded, table-owning language, and that is the biggest adjustment for a developer whose M3 instincts were built entirely around calling a governed API from outside the Business Engine.