Fix | Allow writing DateOnly instance as a Variant parameter

[edwardneal]

Description

This resolves an issue described in #3953: when passing a DateOnly instance as a parameter with a SqlDbType of Variant, the current response is an exception with message:

The incoming tabular data stream (TDS) protocol stream is incorrect. The stream ended unexpectedly.

This exception is legitimate, and it's a result of WriteSqlVariantValue and WriteSqlVariantDataRowValue not containing a code path which writes the data - so we're only sending the sql_variant header. Adding these code paths resolves the issue and eliminates the exception.

Issues

Fixes #3953.

Testing

The existing DateTimeVariantTests have been modified to add test coverage.

[ErikEJ]

@edwardneal Would this also fix #3934 ?

[edwardneal]

While it's definitely a good idea to retest once CI has run, I don't know if it'll fix that specific issue. I wasn't able to reproduce it in the first instance, and only bumped into this while testing other scenarios adjacent to it. There are a pair of currently-unreported bugs which crop up when sending DateOnly instances as values in a sql_variant TVP field, and if that code path is being exercised then the #3934 will need a deeper fix.

[github-actions]

This pull request has been marked as stale due to inactivity for more than 30 days.

If you would like to keep this pull request open, please provide an update or respond to any comments. Otherwise, it will be closed automatically in 7 days.

[edwardneal]

This PR is not stale.

[ErikEJ]

@edwardneal I got help from AI with some analysis of your fix, and it looks like it might well fix #3934

• Fix | Allow writing DateOnly instance as a Variant parameter #4294 is the correct fix; merging it resolves both Cannot send DateOnly instance as a SqlDbType.Variant-typed parameter #3953 and the customer's Support sql_variant containing DateOnly as native SQL date without client conversion #3934.
• Worth noting on Support sql_variant containing DateOnly as native SQL date without client conversion #3934 that (a) the pure-ADO.NET inferred path already produces date correctly, and (b) the failure occurs only when SqlDbType.Variant is forced — which is what EF Core does for sql_variant columns — so the fix lands on the EF scenario.
• One gap in the PR: its tests cover DateOnly.MinValue/MaxValue via TVP/BulkCopy variations, but not the simplest scalar SELECT @p with SqlDbType.Variant from Cannot send DateOnly instance as a SqlDbType.Variant-typed parameter #3953's repro. A 3-line direct test of that exact case would be a worthwhile add.

[cheenamalhotra]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).