JDBC DatabaseMetadata.getFunctions does not return user defined scalar functions from lakehouse

[n_campbell]

One or more scalar/tabular user defined functions are declared in a lakehouse.

Connection established via Microsoft SQL Server JDBC driver to a lakehouse end point.

When DatabaseMetadata.getFunctions is called.

It returns an empty Resultset (cannot find functions) for the specified catalog, schema (name or pattern), function (name or pattern).

Is this a known limitation/defect?

System.out.println("Get functions");
int i = 0;
try (ResultSet rsFunctions = dbMeta.getFunctions("xxyyzz", "%", "F%");) {
while (rsFunctions.next()) {
System.out.println(rsFunctions.getString(1) + "." + rsFunctions.getString(2) + "."
+ rsFunctions.getString(3));
++i;
}
}
System.out.println("Functions found " + i);

[v-sgandrathi]

Hi @n_campbell,

I wanted to check if you had the opportunity to review the information provided by @tayloramy. Please feel free to contact us if you have any further questions. 

Thank you and continue using Microsoft Fabric Community Forum.

[v-sgandrathi]

Hi @n_campbell,

Just looping back to check if everything's good on your end. Let me know if you need any final support happy to assist if anything’s still open.

Thank you.

[v-sgandrathi]

Hi @n_campbell,

Just wanted to follow up and confirm that everything has been going well on this. Please let me know if there’s anything from our end.
Please feel free to reach out Microsoft fabric community forum.

[tayloramy · Accepted solution]

Hi @n_campbell, 

It’s a limitation of the Lakehouse SQL analytics endpoint today.

You can create and call T-SQL functions in a Lakehouse, but the endpoint’s metadata surface is incomplete and doesn’t populate JDBC DatabaseMetaData.getFunctions (and similarly getProcedures). The same code works against a Fabric Warehouse because Warehouse now exposes UDF metadata via the JDBC driver. See: Lakehouse SQL endpoint overview (note that it’s read-only over Delta but lets you define functions) docs, and Warehouse UDF support announced in 2025 blog and blog. For how getFunctions is supposed to work in the SQL Server JDBC driver, see docs. There’s also another thread confirming that Lakehouse returns nothing while Warehouse does return metadata community.

Practical workarounds:

1. If you need discoverability via JDBC metadata, point the code at a Warehouse (even a lightweight one) instead of the Lakehouse endpoint.
2. From Lakehouse, enumerate functions with a direct T-SQL query (catalog views are partially available; may vary by tenant):

-- May work in Lakehouse SQL endpoint; not guaranteed in all tenants SELECT SCHEMA_NAME(o.schema_id) AS schema_name, o.name AS function_name, o.type_desc FROM sys.objects AS o WHERE o.type IN ('FN','TF','IF') -- scalar, table-valued, inline table-valued ORDER BY schema_name, function_name; 

If sys.objects isn’t exposed, try INFORMATION_SCHEMA.ROUTINES (coverage can be limited in Lakehouse):

SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_TYPE = 'FUNCTION' ORDER BY ROUTINE_SCHEMA, ROUTINE_NAME; 

1. As a last resort, maintain a small registry table of functions during deployment and query that table instead of JDBC metadata.

Sanity check: ensure the first parameter you pass to getFunctions is the Lakehouse SQL endpoint catalog (the Lakehouse’s database name). You can also pass null for catalog and schema to let the driver use the current database/schema. But even with correct patterns, Lakehouse currently returns an empty result set via JDBC.

If this behavior blocks you, I’d recommend logging or upvoting an idea. In the meantime, Warehouse is the safest path when your tooling relies on JDBC metadata discovery.

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.