Every data type SQL Server ships with, in the groups of its documentation (dataTypeCategory). The three CLR system types are here because the catalog lists them; hmssql neither decodes nor sends their values. float(n) is stored as real or float, and sysname is nvarchar(128): neither is a type of its own.

The type's name in T-SQL and in sys.types, except that TyRowVersion is rowversion (the catalog says timestamp, the older name, which dataTypeFromName accepts).

The type of a name as sys.types or T-SQL spells it, ignoring case and surrounding space: the inverse of dataTypeName, plus the aliases timestamp (TyRowVersion) and sysname (TyNVarChar). Nothing for a user-defined type, and for a type newer than this library.

The groups of SQL Server's data type documentation.

The group of SQL Server's documentation the type is listed under.

A data type with its arguments: what a column is declared as.

A type's arguments. Which a type takes is fixed (sqlTypeProblem): a length for the character and binary types, a precision and scale for decimal and numeric, a scale for time, datetime2 and datetimeoffset, dimensions for vector, nothing or a schema collection for xml, and nothing for the rest.

The declared length of a character or binary type: in characters (nvarchar(50) is Length 50, whatever its storage takes), or in bytes for the binary types.

The type as T-SQL declares it: nvarchar(50), varbinary(max), decimal(10,2), time(4), vector(3), xml([dbo].[Person]), int. Rendered as it is; check sqlTypeProblem first for a type built by hand.

Why this isn't a type SQL Server has, if it isn't: an argument the type doesn't take, a missing one (the length of an nvarchar, the precision and scale of a decimal, ...; nothing is defaulted), or one out of range: a length outside 1 through 8000 (4000 for nchar and nvarchar), max on a fixed-length type, a precision outside 1 through 38 or a scale above it, a scale above 7, dimensions below 1.

The data type a column or parameter of this wire type was declared as, as far as the wire says: a json column arrives as nvarchar(max), a vector as varchar and a rowversion as binary(8), and that is what they come back as. Nothing for TINull, for a CLR user-defined type other than the three system ones, and for a width the wire doesn't have (a TIIntN 3).

One case match, and the results are constants, so it costs nothing to call per value: Hmssql.Decoding classifies columns with it, on every row for a RowDecoderMonadic.

The type with its arguments: typeInfoDataType plus the length, precision and scale or schema collection the wire carries. This allocates the result, so prefer typeInfoDataType where the arguments don't matter.

The wire type to declare a parameter of this type with, as RawParam's: the nullable encodings, the server's default collation for character types, a schema collection in the current database. Nothing for a type with a sqlTypeProblem, and for json, vector and the CLR types, which a TDS 7.4 or 8.0 client can't send as such (send json as nvarchar(max), a vector as its JSON array text).

The declared type of a result set's column, as far as its metadata says. The user-type tag identifies rowversion; otherwise this is typeInfoSqlType of the column's storage type. An alias type's user ID does not carry its name, so its underlying type is returned.