SqlDataReader.GetDecimal silently truncates decimal(38,18) precision

[priyankatiwari08]

Describe the bug

When reading a decimal(38,18) column from a SqlDataReader, the precision is silently truncated to decimal(28,14). This causes financial calculations to lose precision and produce incorrect results.

To reproduce

using var connection = new SqlConnection(connectionString);
await connection.OpenAsync();

// Create table with high-precision decimal
await new SqlCommand("CREATE TABLE #Test (Value decimal(38,18))", connection).ExecuteNonQueryAsync();
await new SqlCommand("INSERT INTO #Test VALUES (12345678901234567890.123456789012345678)", connection).ExecuteNonQueryAsync();

using var reader = await new SqlCommand("SELECT Value FROM #Test", connection).ExecuteReaderAsync();
await reader.ReadAsync();

var value = reader.GetDecimal(0);
Console.WriteLine(value); // Expected: 12345678901234567890.123456789012345678
                          // Actual:   12345678901234567890.12345678901235 (truncated!)

Expected behavior

GetDecimal should return the full decimal(38,18) value without precision loss.

Actual behavior

The value is silently truncated to approximately 28 significant digits. No exception or warning is thrown.

Further technical details

Microsoft.Data.SqlClient version: 6.0.0
Target framework: .NET 8.0
SQL Server version: SQL Server 2022 (16.0.4135)
Operating system: Windows 11 23H2

The issue appears to be in the TDS parser where the decimal scale/precision from the column metadata isn't fully propagated to the CLR decimal type conversion.

[github-actions]

🔍 Triage Summary

Check	Result
Issue type	Bug
Environment	All required environment details provided for investigation
Area	Area\\Netcore
Duplicates	Potentially related: dotnet/SqlClient#924 (decimal precision loss in TVP via DataReader — different code path, same underlying concern)
Regression	Not indicated

Analysis

SqlDataReader.GetDecimal(int) converts the SQL Server decimal(38,18) value to a CLR System.Decimal, which natively supports only 28–29 significant digits. SQL Server's decimal(38,x) can encode up to 38 significant digits, so any value exceeding ~28–29 significant digits will lose precision when mapped to CLR decimal. The TDS parser translates the on-wire SqlDecimal (full 38-digit precision) to a CLR Decimal via SqlDecimal.ToDecimal(), which performs this silent truncation without raising an exception or warning. This is a P2 issue: the precision loss is silent and materially affects financial calculations.

Next Steps

Assign to Copilot coding agent to investigate the decimal conversion path in TdsParser and SqlDataReader:

• Trace the path from TdsParser.TryReadSqlValueInternal / TryReadDecimalValue into SqlBuffer and the eventual GetDecimal call to identify where SqlDecimal → decimal conversion discards digits.
• Evaluate whether GetDecimal should throw OverflowException (or emit a warning via SqlInfoMessage) when the SQL value exceeds CLR decimal precision, rather than silently truncating.
• Confirm that the existing GetSqlDecimal(int) method (returns SqlDecimal with full 38-digit precision) is the recommended workaround and update XML docs on GetDecimal accordingly.
• Add unit/functional tests covering decimal(38,x) round-trip scenarios for both GetDecimal (overflow/truncation behavior) and GetSqlDecimal (full precision preservation).

Generated by SqlClient Issue Auto-Triage for issue #22 · ● 3.1M · ◷

[priyankatiwari08]

/triage

[github-actions]

🔍 Triage Summary (on-demand re-triage)

Check	Result
Issue type	Bug
Environment	All required environment details provided for investigation
Area	Area\Netcore
Duplicates	Potentially related: dotnet/SqlClient#924 (decimal precision in TVP/DataReader — same underlying concern, different code path)
Regression	Not indicated

Analysis

SqlDataReader.GetDecimal(int) silently truncates SQL Server decimal(38,18) values because CLR System.Decimal only supports 28–29 significant digits. The TDS parser correctly reads the full SqlDecimal (38-digit) value off the wire, but the conversion to CLR decimal via SqlDecimal.ToDecimal() drops excess digits without throwing or warning. This is a P2 issue: silent precision loss is especially harmful in financial contexts, and the behavior diverges from what users reasonably expect when using a column type explicitly declared at decimal(38,18).

Next Steps

Assign to Copilot coding agent to investigate the decimal conversion path:

• Trace TdsParser.TryReadSqlValueInternal / TryReadDecimalValue → SqlBuffer → SqlDataReader.GetDecimal to pinpoint where SqlDecimal → decimal truncation occurs.
• Evaluate whether GetDecimal should throw OverflowException (consistent with CLR type semantics) when the SQL value exceeds CLR decimal precision, rather than silently truncating.
• Confirm GetSqlDecimal(int) (returns SqlDecimal preserving full 38-digit precision) is the correct workaround; update XML docs on GetDecimal to document the precision limitation and recommend GetSqlDecimal for high-precision scenarios.
• Add unit/functional tests covering decimal(38,x) round-trip for both GetDecimal (truncation/overflow behavior) and GetSqlDecimal (full-precision preservation).

Note: This triage summary is auto-generated by an AI agent. The analysis and suggestions above have not been verified by a human maintainer. Please treat as preliminary guidance only.

Generated by SqlClient Issue Auto-Triage for issue #22 · ● 1.3M · ◷