hibernate/hibernate-orm · error · QueryException

Dialect [" + dialect.getClass().getName() + "] not known to

Error message

Dialect [" + dialect.getClass().getName() + "] not known to support REF_CURSOR parameters

What it means

StandardCallableStatementSupport captures the dialect's REF_CURSOR capability (Dialect#supportsRefCursors()) when it is created, and verifyRefCursorSupport throws QueryException 'Dialect [...] not known to support REF_CURSOR parameters' when a ParameterMode.REF_CURSOR registration is used despite that flag being false. The check fails fast instead of rendering a JDBC call the driver cannot execute.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/procedure/internal/StandardCallableStatementSupport.java:115

			}
		}

		buffer.append( ")}" );

		builder.setCallableName( buffer.toString() );
		return builder.buildJdbcCall();
	}

	protected void appendNameParameter(
			StringBuilder buffer,
			ProcedureParameterImplementor<?> parameter,
			JdbcCallParameterRegistration registration) {
		buffer.append( '?' );
	}

	private void verifyRefCursorSupport(Dialect dialect) {
		if ( ! supportsRefCursors ) {
			throw new QueryException( "Dialect [" + dialect.getClass().getName() + "] not known to support REF_CURSOR parameters" );
		}
	}
}

View on GitHub (pinned to fad1729dce)

Solutions

1. Remove the REF_CURSOR registration and consume the implicit result sets: outputs.getResultList() / getResults() or StoredProcedureQuery.getResultList()
2. Guard with dialect.supportsRefCursors() and branch to a dialect-specific call path
3. On databases without REF_CURSOR parameters, rewrite the procedure to SELECT the rows back and read them as returned result sets
4. Use the correct versioned dialect (OracleDialect, PostgreSQLDialect, ...) so capability detection matches the server

Example fix

// before
call.registerParameter(1, void.class, ParameterMode.REF_CURSOR);

// after (SQL Server / Sybase: implicit result sets)
StoredProcedureQuery q = em.createStoredProcedureQuery("list_orders");
q.execute();
List<?> orders = q.getResultList();

Dialect dialect = session.getJdbcServices().getJdbcEnvironment().getDialect();
if (dialect.supportsRefCursors()) {
    call.registerParameter(1, void.class, ParameterMode.REF_CURSOR);
} else {
    // no REF_CURSOR support: consume implicit result sets via getResults()/getResultList()
}

try {
    call.execute();
} catch (org.hibernate.QueryException e) {
    if (e.getMessage().contains("REF_CURSOR")) {
        // dialect lacks REF_CURSOR support: drop the cursor registration and read implicit result sets
    }
}

When it happens

Trigger: call.registerParameter(1, void.class, ParameterMode.REF_CURSOR) or Jakarta registerStoredProcedureParameter(..., ParameterMode.REF_CURSOR) on dialects where supportsRefCursors() returns false — SQL Server, Sybase ASE, H2, older MySQL/MariaDB dialects.

Common situations: Porting Oracle/PostgreSQL REF_CURSOR procedure code to SQL Server or Sybase; integration tests running against H2 while production uses Oracle; upgrading Hibernate where dialect capability detection changed; using a generic dialect instead of the versioned one.

Related errors

• Unexpected error extracting REF_CURSOR parameter [{}]
• Dialect [" + procedureCall.getSession().getJdbcServices().ge
• JDBC driver does not support named parameters for setArray.
• GaussDB only supports REF_CURSOR parameters as the first par
• GaussDB only supports accessing REF_CURSOR parameters by pos

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/14ca49cf20844077. Report an issue: GitHub.