At 04:24:57 Gulf Standard Time (GST) on 2 October 2026, the Dubai Land Department's exact 1 to 30 September residential Sales query returned 11,134 rows. Across 21 declared English-facing analysis fields, MASTER_PROJECT_EN was null in 11,091 rows, or 99.61%, while 11 declared fields including transaction date, area and value had no literal nulls.

Which returned fields carry nulls?

Ten of the 21 declared fields had at least one literal null; 11 had none. The table is ordered by null share and uses the saved response to the Dubai Land Department Real Estate Data query, accessed 2 October 2026. Dubai Land Department, or DLD, is the official property registry authority whose public interface issued the response.

Every row contributes once to each line. For each field, nulls plus non-nulls equals 11,134. All 21 keys were present in every row, and none used an empty string. The counts come from the saved official transaction response captured 2 October 2026; the response endpoint accepts the interface's POST request but is not a resolving reader page.

The useful read is not that one column is good and another is bad. It is that each comparison needs a declared denominator. A project-name analysis can use the 10,344 non-null PROJECT_EN rows if it clearly excludes the 790 nulls. A master-project analysis has only 43 non-null rows in this capture, so any result based on that field describes a much narrower returned subset.

Which fields are populated enough for comparison?

The 11 zero-null fields are the cleanest starting set for a population-wide comparison, but a zero-null count is only a completeness test. It does not prove uniqueness, stable meaning or a useful identifier.

TRANSACTION_NUMBER illustrates the distinction. All 11,134 rows have a value, but the response contains 11,131 distinct transaction-number strings. The row population and the distinct transaction-number population are therefore different measures. The 30 September capture methodology makes the same row-versus-identifier distinction.

PROPERTY_ID provides the opposite edge case. It is one of the 50 returned keys and is never null, yet its numeric value is 0 in all 11,134 rows. This audit records that fact without treating 0 as a usable property identifier.

Field identity also matters. The numeric IS_FREE_HOLD field contains 143 nulls, 375 zeroes and 10,616 ones. The separate English label IS_FREE_HOLD_EN has no nulls and returns 10,616 Free Hold labels and 518 Non Free Hold labels. Those are different returned columns. A comparison should declare which one it uses rather than transferring the completeness of the label to the numeric field.

What changed from the 30 September capture?

The matched historical comparison is narrow: the parsed query values are identical, and both responses expose the same 50 field names. Under those conditions, the 30 September response had 10,770 rows and the 2 October response had 11,134, a difference of 364 rows or 3.38%. This compares two capture-level populations. It does not claim that a particular record was revised.

The null count rises when the population grows, so the share is the more useful capture-level comparison. Even then, a changed share does not identify which rows were added, removed or altered. A row-level revision test would need a stable matching rule and a separate comparison of the matched records.

What does a null prove?

A null proves one thing in this audit: the exact key exists in the returned row and its JSON value is null. It does not mean numeric zero, an empty string or a missing key. The code checks those states separately.

The limit is equally important. A null NEAREST_METRO_EN does not prove that no Metro station is nearby. A null PROJECT_EN does not prove that the property has no project relationship. A null MASTER_PROJECT_EN does not prove that DLD has no master-project record on another surface. The DLD data-source map shows why transaction, project, unit and other official records must keep their own identities.

This is also why the audit does not impute values. Filling a null from a shared name, nearby row or another service would create a derived field. That may be a separate research method, but it would no longer be a count of the exact DLD response.

Method and reproducibility record

The fresh request repeated the declared September query on 2 October 2026. DLD's public interface exposes Sales and Residential filters, and its official publicData.js page script declares the transaction parameter names used below. The returned rows themselves all carry GROUP_EN: Sales and USAGE_EN: Residential.

The saved program counts literal nulls and non-nulls for all 50 returned keys, then checks every sum against the row population. It also checks for missing keys, blank strings, repeated totals, the row-number sequence, query equality and field-name equality. Every reconciliation passed on the 2 October files.

FAQ, checked 2 October 2026

How can I check Dubai real estate transactions?+

Start with the official DLD Real Estate Data interface. For a reproducible comparison, save the exact filters, raw response and access time, then name whether a count refers to rows, distinct transaction numbers or another returned field.

Does null mean zero in DLD transaction data?+

No. In this audit, null means the exact returned JSON value is null. Numeric zero, an empty string and a missing key are separate states.

Which DLD fields had no nulls in this capture?+

Eleven declared fields had 0 literal nulls: ACTUAL_AREA, AREA_EN, GROUP_EN, INSTANCE_DATE, IS_FREE_HOLD_EN, IS_OFFPLAN_EN, PROCEDURE_AREA, PROP_TYPE_EN, TRANSACTION_NUMBER, TRANS_VALUE and USAGE_EN.

Is the 2 October extraction a final September total?+

No. It is a response captured on 2 October 2026 for the declared 1 to 30 September filter. The public DLD interface did not expose a formal finalisation boundary when accessed that day.