The statement-by-statement translation from SuiteScript's record/search API to X++'s embedded SQL — search.create().run().each() to while select, record.load() to select firstonly, record.submitFields() to a targeted update, a Map/Reduce sweep to update_recordset — and what happens when the governance-unit meter disappears and static typing arrives.
The previous chapter was about the shape of the platform: account-resident customisation against compiled, source-controlled packages. This chapter is about the day job — the statements you type, the field you validate, the loop you write on a Tuesday afternoon.
Three surface differences and nothing else. firstonly plays the role of loading a single record by key. Equality is ==, and conjunction is &&. Fields are read through a table buffer — a variable declared with the table's type — using dot notation and compile-time field names, rather than a string-keyed getValue call.
Every SuiteScript execution — a Scheduled Script, a Map/Reduce stage, a User Event, a RESTlet call — runs against a governance-unit budget: a fixed number of usage units per execution (10,000 for a Scheduled Script, smaller allotments for other types), where a record.load() costs 10 units, a search.run() costs 10, a record.save() costs…
SuiteScript has no explicit transaction control across records. Each record.save() (or submitFields(), or Map/Reduce map-stage write) commits on its own, as an implicit unit of work.
Every NetSuite record has an internal id — a tenant-unique integer, stable within the account, meaningless outside it. Every D365 table row has a RecId — a 64-bit surrogate key, unique within the table, allocated by the platform.
The nine SuiteScript entry points each have a natural D365 home. The table below is the anchor; the career guide's extensibility-model comparison expands on governance-unit figures per type.
SuiteScript is dynamically typed JavaScript. A field can hold a string today and, if a script is careless, something else tomorrow; a typo in a field id compiles fine and fails — or worse, silently returns undefined — at runtime. X++ closes that gap with a static type system:
The clearest way to feel the shape of the change is to write the same requirement on both platforms. Requirement: a sales order line's quantity must not exceed the item's available inventory at the fulfilling location before the order saves.
X++ asks you to do everything a SuiteScript developer already does well — think in sets, filter before you loop, keep data access close to the code that needs it — and adds a compiler and a transaction model that mean what they say.