UDT parameters are limited to 64K

[ajcvickers]

This is an issue because serialized spatial types can easily be bigger than this. See dotnet/efcore#18813.

@Wraith2 pointed to the place in the code where this limitation exists:

SqlClient/src/Microsoft.Data.SqlClient/netcore/src/Microsoft/Data/SqlClient/TdsParser.cs

Lines 9027 to 9029 in d0672d2

	//it may be legitimate, but we dont support it yet
	if (size < 0 || (size >= ushort.MaxValue && maxsize != -1))
	throw new IndexOutOfRangeException();

/cc @bricelam

[cheenamalhotra]

It seems that the driver can support larger data size for UDT Types (upto 2 GB, i.e. max LOB size, identified by 0x7FFFFFFF token with length as -1, identified by 0xFFFF token), as introduced in TDS 7.3, but the support was not added to the driver.

Quoting MS TDS:

The value 0xFFFF signifies the maximum LOB size indicating a UDT with a maximum size greater than 8000 bytes (also referred to as a Large UDT; introduced in TDS 7.3).

This applies to both .NET Framework and .NET Core.
Issue would be categorized as an enhancement.

[Wraith2]

That shouldn't be too hard to fix. If i get time i'll have a go. I'd also like to change the exception type that it throws and give a sensible message to the user explaining why they're getting the error. A default IndexOutOfRange exception makes it look like an internal problem (fooled me when i was investigating) rather than something the user can address.

[Wraith2]

How do you get the connection tds protocol version?There's a major+minor version on the session but that doesn't seem to get used. There's also _isYukon _isKatmai _isDenali on the parser but I'm not sure how they map to protocol versions.

[cheenamalhotra]

@Wraith2

TDSParser when parses tokens calls this method for LOGINACK token:

SqlClient/src/Microsoft.Data.SqlClient/netcore/src/Microsoft/Data/SqlClient/SqlInternalConnectionTds.cs

Lines 1947 to 1961 in 1a0748e

	internal void OnLoginAck(SqlLoginAck rec)
	{
	_loginAck = rec;
	if (_recoverySessionData != null)
	{
	if (_recoverySessionData._tdsVersion != rec.tdsVersion)
	{
	throw SQL.CR_TDSVersionNotPreserved(this);
	}
	}
	if (_currentSessionData != null)
	{
	_currentSessionData._tdsVersion = rec.tdsVersion;
	}
	}

[aprognimak]

Ehm, guys, any workaround (no matter how ugly)?
This used to work in 2.2 and it really is not an enhancement but a breaking bug

[Wraith2]

It didn't work in 2.2. It's been this way since the inception of the feature, the only thing that can have changed is the amount of data you feed it. I'm working my way through the fix but I've got a few things going on at the minute so it's a bit slow.

[ajcvickers]

@bricelam Is it possible that EF Core didn't hit this in 2.2 because it was using a different mechanism that didn't hit this exact code path? (I don't remember exactly what we changed here.)

[aprognimak]

It didn't work in 2.2. It's been this way since the inception of the feature, the only thing that can have changed is the amount of data you feed it. I'm working my way through the fix but I've got a few things going on at the minute so it's a bit slow.

Well it did. Just triple hours ago I was on 2.2 using the olden NetTopologySuite types, those IGeometry and all that stuff. However saving changes to the context when using spatial data even when there were no changes took enormous time (minutes for 1k+ shapes, unchanged) so I moved to 3.0.1 and it just stopped working.
Now I can't reseed my db with us state county borders because even with the least accuracy some of those don't fit into 64k parameter value. 2.2 most likely used quite different approach when dealing with spatial data given it was just introduced then.

Trying postgres now.

[capesean]

Ehm, guys, any workaround (no matter how ugly)?
This used to work in 2.2 and it really is not an enhancement but a breaking bug

I’m using ExecuteSqlRaw with geometry::STGeomFromText('{geometry.ToString()}' as a temporary fix.

[bricelam]

EF Core didn't hit this in 2.2 because it was using a different mechanism

Correct. We were using SqlBytes parameters (not UDTs) in 2.2. We switched to UDTs in 3.0 to fix dotnet/efcore#14595

[ajcvickers]

@cheenamalhotra I think this raises the priority of getting this changed, since without it customers using spatial with EF Core will be running into blocking issues. Hopefully @Wraith2 will come up with a fix, but if not can we raise the priority of getting this in?