Results Grid truncates fractional seconds and ignores SQL Server datetime precision
Summary
Data grid does not display fractional seconds in the Results Grid according to the actual precision defined by SQL Server datetime datatypes. The grid appears to default to millisecond display regardless of the underlying column scale.
Problem Description
SQL Server supports multiple datetime-related datatypes, each with well-defined precision and storage semantics:
smalldatetime (minute precision)
datetime (fixed, ~3.33 ms increments)
datetime2(p) where p = 0 through 7
datetimeoffset(p) where p = 0 through 7
expressions such as AT TIME ZONE, which return datetimeoffset(7)
In dbForge Studio for SQL Server version 2025.2.138, the Results Grid does not display fractional seconds based on the actual datatype precision. Instead, values are rendered as if they were millisecond-based, even when the underlying column type is datetime2(5), datetime2(7), or datetimeoffset(7).
As a result, higher precision stored in SQL Server is visually truncated in the grid, which is misleading. All datetime values appear to show only 3 fractional digits. Higher precision values (5 or 7 digits) are not displayed. No visible distinction between datetime2(3) and datetime2(7)
Expected Behavior
The Results Grid should display fractional seconds based on the actual SQL Server datatype precision, for example:
smalldatetime: no fractional seconds
datetime: SQL Server-defined millisecond resolution
datetime2(0): no fractional seconds
datetime2(3): 3 fractional digits
datetime2(5): 5 fractional digits
datetime2(7): 7 fractional digits
datetimeoffset(7): 7 fractional digits plus timezone offset
This matches the behavior of SQL Server Management Studio and Azure Data Studio and is critical for accurate inspection of time-sensitive data.
Reproduction Transact-SQL code:
SET NOCOUNT ON;
IF OBJECT_ID('tempdb..#TestDates') IS NOT NULL
DROP TABLE #TestDates;
CREATE TABLE #TestDates
(
RowId int IDENTITY(1,1) PRIMARY KEY,
Dt_smalldatetime smalldatetime,
Dt_datetime datetime,
Dt_datetime2_0 datetime2(0),
Dt_datetime2_3 datetime2(3),
Dt_datetime2_5 datetime2(5),
Dt_datetime2_7 datetime2(7),
Dt_datetimeoffset_7 datetimeoffset(7)
);
INSERT INTO #TestDates
(
Dt_smalldatetime,
Dt_datetime,
Dt_datetime2_0,
Dt_datetime2_3,
Dt_datetime2_5,
Dt_datetime2_7,
Dt_datetimeoffset_7
)
VALUES
(
CAST('2026-02-03T14:32:00' AS smalldatetime),
CAST('2026-02-03T14:32:10.123' AS datetime),
CONVERT(datetime2(0), '2026-02-03T14:32:10', 126),
CONVERT(datetime2(3), '2026-02-03T14:32:10.123', 126),
CONVERT(datetime2(5), '2026-02-03T14:32:10.12345', 126),
CONVERT(datetime2(7), '2026-02-03T14:32:10.1234567', 126),
TODATETIMEOFFSET(CONVERT(datetime2(7), '2026-02-03T14:32:10.1234567', 126), '+00:00')
);
-- What the data grid displays by default
SELECT
RowId,
Dt_smalldatetime,
Dt_datetime,
Dt_datetime2_0,
Dt_datetime2_3,
Dt_datetime2_5,
Dt_datetime2_7,
Dt_datetimeoffset_7
FROM #TestDates;
-- what is expected to be shown in the data grid
SELECT
RowId,
CONVERT(varchar(50), Dt_smalldatetime, 126) AS SmallDt_rounded_minute_precision,
CONVERT(varchar(50), Dt_datetime, 126) AS Dt_datetime_quantized,
CONVERT(varchar(50), Dt_datetime2_0, 126) AS Dt2_0_expected_0_digits,
CONVERT(varchar(50), Dt_datetime2_3, 126) AS Dt2_3_expected_3_digits,
CONVERT(varchar(50), Dt_datetime2_5, 126) AS Dt2_5_expected_5_digits,
CONVERT(varchar(50), Dt_datetime2_7, 126) AS Dt2_7_expected_7_digits,
CONVERT(varchar(50), Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time', 126) AS Central_expected_iso,
DATEPART(TZOFFSET, Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time') AS Central_expected_tzoffset_minutes
FROM #TestDates;
-- show precision for each datatype
SELECT
RowId,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_smalldatetime), 'Scale') AS Scale_smalldatetime,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime), 'Scale') AS Scale_datetime,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_0), 'Scale') AS Scale_datetime2_0,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_3), 'Scale') AS Scale_datetime2_3,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_5), 'Scale') AS Scale_datetime2_5,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7), 'Scale') AS Scale_datetime2_7,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetimeoffset_7), 'Scale') AS Scale_datetimeoffset_7
FROM #TestDates;
-- show basetype and precision for explicit conversions in SELECT
SELECT
RowId,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7), 'BaseType') AS BaseType_dt2_7,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7), 'Scale') AS Scale_dt2_7,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC'), 'BaseType') AS BaseType_utc_as_dto,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC'), 'Scale') AS Scale_utc_as_dto,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time'), 'BaseType') AS BaseType_central_as_dto,
SQL_VARIANT_PROPERTY(CONVERT(sql_variant, Dt_datetime2_7 AT TIME ZONE 'UTC' AT TIME ZONE 'Central Standard Time'), 'Scale') AS Scale_central_as_dto
FROM #TestDates;
IF OBJECT_ID('tempdb..#TestDates') IS NOT NULL
DROP TABLE #TestDates;
Why This Matters
Developers rely on the Results Grid to debug ordering, uniqueness, and event timing
Truncated display can falsely suggest rounding or data loss
This is especially problematic for telemetry, logging, and distributed systems
Displaying fewer fractional digits than are stored is misleading, even if the underlying value is correct
Request
Please restore or add functionality so that the Results Grid:
Displays fractional seconds based on the actual SQL Server datatype precision
Correctly distinguishes between datetime, datetime2(p), and datetimeoffset(p)
Applies this behavior consistently to table columns, computed expressions, and AT TIME ZONE results
Optionally allows overriding the display format, but defaults to datatype-accurate rendering
Environment
dbForge Studio for SQL Server: 2025.2.138
SQL Server version: 2017
-
MEngelbyDA
commented
Sorry for the badly formatted code segment. I'd edit the suggestion to format the code block if this forum supports this feature. Figured it out...yay for markdown!
-
MEngelbyDA
commented
Sorry for the badly formatted code segment. I'd edit the suggestion to format the code block if this forum supports this feature.