The Legacy Obituaries

Notices of desupport & departureOracle Database → AzureTuesday, 29 September 2026The Coroner’s ReportsAbout this paper

Case q10 · version-scope

We plan to move to Oracle 23ai on Azure VMs and use the new SQL BOOLEAN type. Anything to watch in a later hop to Azure SQL?

Expected: BOOLEAN maps to bit in SQL Server (SSMA); also note LogMiner/CDC tooling limits for BOOLEAN if recorded; scoped to 23ai+.

No tools

The model alone, answering from memory.
larger model · 1 turn · 28 s · 16.5k in / 2.8k out

✓ verdict ✗ grounded ✓ cited

Grader: Correct mapping; from-memory claims (sort order, COMPATIBLE) not retrieved

Answer

Verdict: Using BOOLEAN on 23ai is fine, but Azure SQL (Database and Managed Instance) has no native BOOLEAN column type. As far as I know that is still true for SQL Server 2025, but check before you commit. Every BOOLEAN column becomes BIT, and any SQL that treats boolean expressions as values will need rewriting. Write your 23ai code in a portable style now so the later move is a simple type mapping and not a code refactor.

What breaks or changes on the Azure SQL side

  1. Type mapping. BOOLEAN → BIT (0/1/NULL). The data converts cleanly, and T-SQL also accepts the strings 'TRUE'/'FALSE' as BIT values. Oracle's other accepted inputs ('yes'/'no', 'on'/'off', 't'/'f') don't convert, so fix any loaders that rely on them.
  2. Bare predicates. 23ai lets you write WHERE is_active, WHERE NOT is_active and CASE WHEN flag THEN. T-SQL requires WHERE is_active = 1.
  3. Booleans as values. 23ai lets you write SELECT a > b AS flag or SET flag = (x IS NULL). T-SQL doesn't; you need CASE WHEN a > b THEN 1 ELSE 0 END.
  4. IS [NOT] TRUE/FALSE tests and the TRUE/FALSE literals. T-SQL supports neither, so rewrite them as = 1, = 0 or IS NULL logic.
  5. Aggregates. Oracle's BOOLEAN_AND_AGG and BOOLEAN_OR_AGG have no T-SQL equivalent. MIN, MAX and SUM also reject BIT directly, so you need MAX(CAST(flag AS int)).
  6. Text output. TO_CHAR(bool) and concatenation produce 'TRUE'/'FALSE' in Oracle, but '1'/'0' from BIT in T-SQL. Check reports, CSV exports and string comparisons.
  7. NULL sort order. Oracle puts NULLs last in ascending order; SQL Server puts them first. This affects nullable flag columns used in ORDER BY.
  8. Tools and connectors. Confirm that your SSMA for Oracle version supports 23ai as a source and maps SQL BOOLEAN (PL/SQL BOOLEAN has long been supported). Do the same for your ADF, DMS or Oracle connector version. Don't assume 23ai-only types pass through; test with a sample table early.
  9. Clients. Usually low risk: JDBC getBoolean() and .NET bool both work with BIT. The exceptions are raw SQL strings with Oracle literals and ORM dialect settings.

Recommendations for the 23ai phase

  • Always compare explicitly (flag = TRUE). Don't select predicates as values or use the boolean aggregates. That keeps the later rewrite mechanical (TRUE → 1).
  • If a quick Azure SQL move is likely, consider NUMBER(1) with CHECK (col IN (0,1)) for new tables. It maps 1:1 to BIT and needs no code changes.
  • SQL BOOLEAN needs COMPATIBLE set to 23 or higher on the Oracle side, and that setting can't be reversed.
  • Add a lint or grep rule to find the patterns above so the conversion work stays measurable.

Sources

I wrote this from memory without looking anything up, so check the SSMA/ADF support for 23ai and the current Azure SQL type list before you plan around them.

Keyword search

BM25 over the same 446 documents: top 8 passages pasted in, one pass, references not followed.
larger model · 1 turn · 12 s · 18.9k in / 1.2k out

✓ verdict ✓ grounded ✗ cited

Grader: BOOLEAN→bit via SSMA, 23ai scope; claims cite passages

8 keyword-search passages
  1. feature_boolean-23ai score 25.893
  2. mapping_data-pump--azure-dms score 21.008
  3. mapping_boolean-23ai--azure-pg-flex score 18.817
  4. feature_stored-outlines score 16.512
  5. mapping_vector-datatype--azure-sql-db score 16.331
  6. mapping_boolean-23ai--azure-sql-db score 16.087
  7. mapping_oracle-streams--azure-dms score 15.911
  8. mapping_stored-outlines--azure-sql-db score 15.83
Answer

Verdict: Yes. Azure SQL has no boolean column type, so every 23ai BOOLEAN you adopt becomes bit in the later hop. Any SQL or PL/SQL that uses a boolean directly as a condition will have to be rewritten.

What to watch

  • The type mapping: SSMA converts BOOLEAN to bit, which stores 0, 1 or NULL. Storage works out the same, so the column mapping itself is fine. [6]
  • Conditions must be rewritten: In SQL Server a bit can't stand alone as a condition. Every WHERE is_active style expression has to become a comparison such as WHERE is_active = 1. [6]
  • NULL handling carries over: NULL bits behave like Oracle's UNKNOWN, so NULL semantics carry over. [6]
  • PL/SQL boolean variables: These must also become bit comparisons in T-SQL. [6]
  • CHECK constraints and defaults: Review any that use TRUE/FALSE literals. [6]
  • Alternate spellings: 23ai lets applications write yes/no, on/off, t/f, y/n and 1/0 into a BOOLEAN column, and treats any non-zero number as TRUE. [1] My sources don't say whether bit accepts those same inputs. If your application relies on them, assume the inputs will need translating and test it.
  • Converting old flag columns: If you plan to turn existing CHAR(1) or NUMBER(1) flag columns into BOOLEAN on 23ai, you have to decide which columns and string conventions to convert. [1] Do that work once, knowing it all ends up as bit on Azure SQL anyway.
  • Migration tooling: For Oracle to Azure SQL, Azure DMS only supports offline migration, is in preview, and runs through SSMA. There is no online (continuous sync) path, so plan a downtime window. For ongoing replication, use GoldenGate, Fabric mirroring or Data Factory. [2][7]

For comparison: If the later hop were to Azure Database for PostgreSQL instead, BOOLEAN would map to PostgreSQL's native boolean with no changes (Ora2Pg does this by default). [3]

Sources: The passages I was given don't include URLs, so I can't cite links. Passage [1] notes that Oracle's 23ai documentation now redirects to the 26ai reference pages.

Sanity Context · GROQ

The agent with the GROQ endpoint: schema, joins, Portable Text.
smaller model · 5 turns · 28 s · 43.6k in / 1.9k out

✓ verdict ✓ grounded ✗ cited

Grader: bit mapping, scoped 23ai/26ai, SSMA source cited

4 tool calls
  1. initial_context on groq · 4,126 chars back
  2. groq_query on groq · 713 chars back
    *[_type=="oracleFeature" && name match "*BOOLEAN*"]{_id, name, slug, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus}
  3. groq_query on groq · 4,199 chars back
    *[_type=="mapping" && oracleFeature._ref=="feature_boolean-23ai"]{
  _id, fidelity, effort, rationale, appliesToOracleVersions,
  "azureTarget": azureTarget->{name, slug, service, tierNotes},
  "sources": sources[]->{title,url,publisher},
  "caveats": *[_type=="caveat" && references(^._id)]{
    severity, statement, appliesTo, firsthand,
    "evidence": evidence->{title,url,publisher}
  }
}
  4. groq_query on groq · 505 chars back
    *[_type=="dispute" && (claimA._ref=="caveat_boolean-ssma-bit" || claimB._ref=="caveat_boolean-ssma-bit")]{title, whatDisagrees, resolution, "claimA": claimA->statement, "claimB": claimB->statement, "resolvedBy": resolvedBy->{title,url}}
Answer

No dispute on this. Here's the answer:

Verdict: Yes — the SQL BOOLEAN type (23ai) does not survive a later hop to Azure SQL Database with exact fidelity; it degrades to a bit column, and boolean expressions used as predicates will need rewriting.

On Azure VMs today (23ai): No mapping is recorded in the dataset for "Oracle on Azure VM" specifically for this feature — since you'd still be running native Oracle 23ai, the BOOLEAN type behaves as documented by Oracle, and no caveat/mapping entry exists for that target in this dataset.

Later hop to Azure SQL Database (fidelity: partial, effort: S, applies to Oracle 23ai/26ai):

  • SQL Server has no native boolean column type. Microsoft's SSMA for Oracle maps Oracle BOOLEAN to bit (stores 0, 1, or NULL) for arguments, return values, and local variables. Storage is equivalent, and three-valued NULL logic mirrors Oracle's UNKNOWN, but every WHERE is_active style predicate must be rewritten as an explicit comparison (e.g., = 1), since bit cannot be used as a standalone predicate. — SSMA for Oracle: Project Settings (Type Mapping) (Microsoft), severity: minor.

Note: No mapping specific to Azure SQL Managed Instance was found for this feature in the dataset — only Azure SQL Database is covered.

Aside (if a PostgreSQL hop is ever on the table instead): the dataset shows Azure Database for PostgreSQL Flexible Server gives exact fidelity — Postgres has a native boolean type usable directly as a predicate, and Ora2Pg can even promote legacy NUMBER(1)/CHAR(1) flags to boolean. — PostgreSQL documentation: Boolean type, Ora2Pg documentation (community).

No disputes are recorded on this point in the dataset.

GROQ + Knowledge Base

The agent with both endpoints.
smaller model · 7 turns · 35 s · 59.3k in / 2.4k out

✓ verdict ✓ grounded ✗ cited

Grader: bit mapping, 23ai/26ai scope, cited quotes; flags gaps

6 tool calls
  1. initial_context on groq · 4,126 chars back
  2. initial_context on kb · 7,679 chars back
  3. groq_query on groq · 751 chars back
    *[_type=="oracleFeature" && (name match "*boolean*" || slug.current match "*boolean*")]{_id, name, slug, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus}
  4. groq_query on groq · 3,164 chars back
    *[_type=="mapping" && oracleFeature._ref=="feature_boolean-23ai"]{
  _id, fidelity, effort, rationale, appliesToOracleVersions,
  "azureTarget": azureTarget->{name, slug, service},
  "sources": sources[]->{title, url},
  "caveats": *[_type=="caveat" && references(^._id)]{
    severity, statement, appliesTo, firsthand,
    "evidence": evidence->{title, url, publisher}
  }
}
  5. groq_query on groq · 703 chars back
    *[_type=="dispute" && (claimA->statement match "*boolean*" || claimB->statement match "*boolean*" || title match "*boolean*" || title match "*Boolean*")]{title, whatDisagrees, resolution, "claimA": claimA->{statement, evidence->{title,url}}, "claimB": claimB->{statement, evidence->{title,url}}, "resolvedBy": resolvedBy->{title,url}}
  6. groq_query on groq · 307 chars back
    *[_type=="pattern" && references("mapping_boolean-23ai--azure-sql-db")]{title, problem}
Answer

No dispute or pattern on this topic. That's sufficient evidence to answer.

Verdict

Moving BOOLEAN columns from Oracle 23ai to Azure SQL Database later is partial fidelity — storage works, but predicate syntax breaks and must be rewritten.

Scoped facts

  • Feature: SQL BOOLEAN datatype, introduced in Oracle 23ai. Your planned Oracle 23ai/Azure VM deployment is in scope for this mapping (appliesToOracleVersions: 23ai, 26ai).
  • Oracle 23ai on Azure VM (first hop): no caveat/mapping issue recorded — this is native Oracle running on IaaS, so the BOOLEAN type behaves as on any Oracle 23ai instance. The dataset has no separate mapping entry for that leg (it's not a cross-platform hop).
  • Later hop → Azure SQL Database: fidelity = partial, effort = S.
    • Rationale: "SQL Server has no boolean column type; SSMA maps BOOLEAN to bit, which stores 0, 1 or NULL and cannot appear as a standalone predicate. Storage is equivalent, but every WHERE is_active style expression must be rewritten as a comparison with 1, and three-valued logic on NULL bits mirrors Oracle's UNKNOWN." — SSMA for Oracle: Project Settings (Type Mapping)
    • Caveat (minor, appliesTo 23ai/26ai): "SSMA maps Oracle BOOLEAN to bit for arguments, return values and local variables (bit stores 0, 1 or NULL), so boolean expressions used directly as predicates or in SELECT lists must be rewritten as comparisons." — same source, publisher Microsoft.
    • What to watch, concretely: any PL/SQL or SQL code using a boolean column/variable directly as a predicate (e.g., WHERE is_active) will need rewriting to an explicit comparison (WHERE is_active = 1) once on Azure SQL DB. NULL-bit semantics do carry over Oracle's three-valued (UNKNOWN) logic, so that behavior itself isn't lost — only the bare-predicate syntax is.

Gaps

  • The dataset has no mapping entry for Azure SQL Managed Instance specifically for this feature — only Azure SQL Database and Azure Database for PostgreSQL Flexible Server are covered. If your later hop targets Managed Instance rather than Azure SQL Database, there's no evidence on file confirming the same SSMA bit-mapping behavior applies, though the source cited (SSMA Type Mapping page) is not DB/MI-specific in its title.
  • No dispute or how-to pattern in the knowledge base touches this specific BOOLEAN-to-bit conversion, so no conflicting claims to report.

← q09All casesq11 →