4GL, DAL and X++ — the language and runtime migration

A statement-by-statement translation of LN's Tools 4GL and DAL into X++: select families, transactions, company scoping and RecId, DAL hooks versus Chain of Command, and the object-oriented model an LN developer has never needed before.

What you will be able to do

Introduction

Part 1 covered the shape of the platform: VRC layering, DAL and DAL2, and D365's extension-first model. This chapter goes one level deeper, into the language itself. If you write Tools 4GL sessions and DAL business object scripts for a living, this is the chapter that tells you, statement by statement, what changes and what does not.

The honest DNA comparison

Tools 4GL and X++ share a common ancestor problem — both exist to let a business developer read, validate and post ERP transactions without hand-writing every SQL statement — but they solve it with different DNA.

Statement by statement: select, retrieve, and the set-based mindset

LN's data access is built around the select ... selectdo ... endselect cursor loop and the db.retrieve / db.insert / db.update / db.delete family for single-row operations. A typical LN 4GL loop over open sales order lines on hold looks like this:

Transactions: reference counting versus ttsbegin/ttscommit

LN's begin.transaction() and commit.transaction() are reference counted at the session level: nested calls increment and decrement a counter, and only the outermost commit.transaction() actually writes. rollback.transaction() undoes everything back to the start of the outermost begin.transaction().

Company scoping and keys: the company number versus DataAreaId and RecId

In LN, the company you are working in is not a column on a row — it is which physical set of tables the session has opened. A sales order in company 100 and a sales order in company 200 live in genuinely separate table instances behind the scenes, even though both are conceptually "the sales order table." The Tools package (ttadv)…

The DAL versus table events and Chain of Command

LN's DAL (Data Access Layer) exposes lifecycle hooks at a granularity most X++ developers initially find more precise than what they are given: before.save.object(), after.save.object(), and field-level check.<field> scripts that fire as a specific field is validated.

The runtime shape: objects, collections, sessions and forms

Object orientation. LN 4GL organises logic into functions grouped into libraries. There is no class, no interface, no inheritance, and no distinction between a static and an instance context, because there is no instance — a 4GL function operates on whatever table buffers and parameters it is given, full stop.

Worked example: the same validation, twice

Consider one concrete business rule end to end: a purchase order line may not be confirmed while the vendor is on payment hold. In LN, this is a DAL hook on the purchase order line business object, evaluated as the line is saved:

Knowledge check

Summary

LN 4GL and X++ solve the same class of problem — validate and post ERP transactions safely — with genuinely different DNA: a session-bound 3GL with embedded SQL against one company's physical tables, versus a compiled, object-oriented, set-based language operating over a single schema partitioned by DataAreaId.