You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is about being able to use properties of .NET types that are registered as UDT types on SQL Server.
This issue is not about supporting SQL Server spatial or hierarchyid types, which happen to be implemented like UDTs. Directly mapping to SQL Server spatial types is already enabled in 2.1 wherever the types are available (currently only .NET Framework), and our full spatial story is tracked at #1100. I am splitting this issue from supporting hierachyid that was originally reported at #365, because I believe in order to property support hierarchyid we would need additional function mapping.
Enabling SQL Server UDTs would involve adding APIs to register custom type mappings and making sure you can issue queries that read values or pass parameters or even literals of these types.
The necessary features were added in SqlClient for .NET Core in 2.1. Note that UDTs need CLR types that are registered on the server and available on the client for the ADO.NET layer. SqlClient’s mechanism happens to be very simple but also inflexible. Here is a call to create a true plug-in model: https://github.com/dotnet/corefx/issues/29139.
The text was updated successfully, but these errors were encountered:
This issue is about being able to use properties of .NET types that are registered as UDT types on SQL Server.
This issue is not about supporting SQL Server spatial or hierarchyid types, which happen to be implemented like UDTs. Directly mapping to SQL Server spatial types is already enabled in 2.1 wherever the types are available (currently only .NET Framework), and our full spatial story is tracked at #1100. I am splitting this issue from supporting hierachyid that was originally reported at #365, because I believe in order to property support hierarchyid we would need additional function mapping.
Enabling SQL Server UDTs would involve adding APIs to register custom type mappings and making sure you can issue queries that read values or pass parameters or even literals of these types.
The necessary features were added in SqlClient for .NET Core in 2.1. Note that UDTs need CLR types that are registered on the server and available on the client for the ADO.NET layer. SqlClient’s mechanism happens to be very simple but also inflexible. Here is a call to create a true plug-in model:
https://github.com/dotnet/corefx/issues/29139.
The text was updated successfully, but these errors were encountered: