@mbellade
I’ve re-examined the issue and identified the root cause: the Dialect was missing a descriptor registration, causing Hibernate to always interpret SQL Server’s JSON as a VARCHAR type. Consequently, I have removed the previous logic and added the appropriate descriptor to the SQL Server Dialect.

Hi @mbellade.
I introduced logic to apply AdjustableJdbcType adaptation even when an explicit JdbcType is provided in InferredBasicValueResolver.
The primary goal was to ensure that JDBC types correctly adapt to metadata like @Nationalized or global property
However, this change causes a regression in LengthTest#testSqlType

• Cause: LongVarcharJdbcType (used for LONG32VARCHAR) implements AdjustableJdbcType. When resolveIndicatedType is called without an explicit length (using default Length.LONG), it downgrades the type code from LONG32VARCHAR
  to the standard LONGVARCHAR.
• Result: H2 Dialect maps LONGVARCHAR to VARCHAR(32600) instead of CLOB, causing a "Value too long" exception when inserting large data. Before this change, the explicit LONG32VARCHAR was preserved, leading to a correct CLOB
  mapping.

I would appreciate guidance on the correct design direction:
Is it the intended behavior to apply AdjustableJdbcType logic to explicitly defined JDBC types?
If we should NOT apply adaptation logic to explicit types, how should we handle JSON on SQL Server? Should we treat it like other DBs and use a single fixed type (e.g., always NVARCHAR(MAX)) regardless of the nationalized attribute, effectively ignoring the attribute for explicit JSON types?

I'm happy to adjust the implementation based on your feedback. For now, I've pushed the changes to facilitate discussion despite the test failure.

Given that the JSON data type or alternative we're using on all other databases is able to store all characters (not just ASCII), I think it might be best to default to add the following to the SQLServerDialect:

		jdbcTypeRegistry.addDescriptor( JsonAsStringJdbcType.NVARCHAR_INSTANCE );
		jdbcTypeRegistry.addDescriptor( XmlAsStringJdbcType.NVARCHAR_INSTANCE );

Or maybe even do that in the AbstractTransactSQLDialect since Sybase ASE probably has a similar problem.

Instead of validating the column type, can you please write a test that stores a unicode character into a JSON string and verify that it comes out the same way again? See StringNationalizedMappingTests as an example.
That way, we will also understand immediately when running the testsuite which database mappings are incorrect.

Hi @beikov
I registered JsonAsStringJdbcType.NVARCHAR_INSTANCE and XmlAsStringJdbcType.NVARCHAR_INSTANCE in AbstractTransactSQLDialect
and added a test that stores and retrieves a Unicode character in a JSON string.
Could you please take another look when you have a chance? Let me know if you need any further adjustments.

@beikov
I update the test code for all database tests.

@beikov
I remove old test and apply override method

It seems we will need to merge #11989 first to get rid of the failure for Sybase.

@beikov
I applied the jTDS driver patch for Sybase to the supportsNationalizedMethods() method usage section.

@beikov I revert STREAM_BINDING binder change and fix import formatting.

@beikov Sorry about that — I re-applied the formatting.
I have a quick question.I ran the spotless command before committing, but some formatting changes weren't applied. Am I misunderstanding how spotless works? I ran command by gradlew :hibernate-core:spotlessApply

Quality Gate failed

Failed conditions
4.5% Coverage on New Code (required ≥ 80%)
34.7% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

I'm sorry this takes so long, but the jTDS driver was posing a problem which wasn't easy to solve. I cleaned up the code now and created a new PR: #12105