Your Oracle instincts now have a T-SQL translation.
What you covered
💡 The Bottom Line, one more time
VARCHAR2/NUMBER/DATE become
VARCHAR/DECIMAL/DATETIME2, || becomes
+ or CONCAT(), ROWNUM pagination gymnastics become a
single OFFSET...FETCH clause, and DUAL simply disappears because
SQL Server never needed it. Standalone sequences give way to IDENTITY columns,
PL/SQL packages give way to schema-qualified standalone procedures, and — the change most
likely to bite you in production — SQL Server autocommits by default while Oracle waits for
an explicit COMMIT. None of your Oracle instincts about relational design are
wrong on SQL Server; the engine underneath is just wired slightly differently, and now you
know where.
What's next
This guide covered the core language mapping. From here, the natural next steps are:
- SQL Server-specific features — window functions, indexed views, temporal tables, and the query optimizer's execution plan tooling (SSMS's "Actual Execution Plan") are worth a dedicated look, since they don't map one-to-one onto Oracle equivalents.
- Database migration tooling — Microsoft's Data Migration Assistant (DMA) and SQL Server Migration Assistant (SSMA) for Oracle can automate much of the schema and code translation this guide covered by hand, and flag the trickier PL/SQL constructs automatically.
- The full SQL Fundamentals track — worth skimming even as an experienced developer, for the idioms this guide didn't have room for.
More transition guides (SQL Server → MySQL, JavaScript → TypeScript) are on the way — no need to go looking elsewhere.