# Stored NULL values come back as 0.0 from history queries (SQL Historian and SDK historians)

**URL:** <https://forum.inductiveautomation.com/t/stored-null-values-come-back-as-0-0-from-history-queries-sql-historian-and-sdk-historians/116753>\
**Category:** Ignition\
**Tags:** ignition83, database\
**Created:** [August 11, 2026, 3:07pm UTC](https://forum.inductiveautomation.com/t/stored-null-values-come-back-as-0-0-from-history-queries-sql-historian-and-sdk-historians/116753 "2026-08-11T15:07:11Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![sam.donche](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/sam.donche/32/86269_2.png) [@sam.donche](https://forum.inductiveautomation.com/u/sam.donche)\
**Post date:** [August 11, 2026, 3:07pm UTC](https://forum.inductiveautomation.com/t/stored-null-values-come-back-as-0-0-from-history-queries-sql-historian-and-sdk-historians/116753/1 "2026-08-11T15:07:11Z")

</div>

We're building a [custom historian module for timescaledb](https://mustrysolutions.com/products-and-tools/ignition-modules/timescaledb) on the 8.3 Historian SDK (gateway 8.3.3) and got a bug report that NULL values in history read back as 0.0. After digging in, it turns out this isn't specific to our module.

What we tested:

1. Stored three good float points (1.5, 2.5, 3.5) with `system.historian.storeDataPoints`, then inserted two rows with NULL values directly in the database: one with good quality (192) and one with the bad quality code we observed Ignition itself produce for a failing tag (-2147483136). Queried the range with `system.historian.queryRawPoints`. Result: 1.5, 0.0, 2.5, 0.0, 3.5. The qualities come back unchanged (192 for the good NULL, -2147483136 for the bad one), but both NULLs turned into 0.0. The good quality NULL is now indistinguishable from a real measured zero.

2. Our module keeps the value as null the whole way: we check `ResultSet.wasNull()` and hand the null to `DataPointFactory.createAtomicPoint`, which internally routes to `createNullPoint`. So the 0.0 appears later, when the platform assembles the query result dataset. As far as we can tell no historian implementation can return a NULL through that layer.

3. For comparison we looked at the stock SQL Historian (historian-sql 1.3.3). In `PartitionDataLoader.getValueFromRS` the numeric columns are read with `rs.getLong` / `rs.getDouble` without a `wasNull()` check, so there a NULL already becomes 0/0.0 at the JDBC level.

Questions:

1. Is the null to 0.0 coercion in query result assembly intended? If so, what is `createNullPoint` meant for?
2. Is there a recommended way for a historian to return "no value at this timestamp" so clients see a gap instead of a fabricated zero?
3. Should the missing `wasNull()` checks in the stock SQL Historian be filed as a bug through support?

Setup: Ignition 8.3.3 in Docker, queries via a WebDev endpoint calling `system.historian.queryRawPoints`, per-point qualities read with `getQualityAt`.