getColumns() API failing when number of columns in database is ~ 32k.

Driver version

8.1.1.jre8-preview

SQL Darawarehouse version

Effective version: Azure SQL Database (ver. 12.0.2531)

Client Operating System

Cent OS 7

JAVA/JVM version

openjdk version "1.8.0_232"

Table schema

Problem description

getColumns() API failing when number of columns in database is ~ 32k.
errorNumber: 103003
vendorCode: 103003
SQLState: S0001
errorMessage: Some part of your SQL statement is nested too deeply. Rewrite the query or break it up into smaller queries.

1. Expected behaviour: Should return all columns
2. Actual behaviour: Error thrown
3. Error message/stack trace: Some part of your SQL statement is nested too deeply. Rewrite the query or break it up into smaller queries.
4. Any other details that can be helpful:

JDBC trace logs

Reproduction code

[mprins]

this appears to be a database error, not a driver error

[ulvii]

Hi @shikharb97 ,
We will investigate and get back to you.

[lilgreenbird]

hi @shikharb97, I am going to create an environment to try to reproduce the issue. To speed things up, can you tell me what your schema looks like and what is the query you are using?

[lilgreenbird]

hi @shikharb97,
I am able to reproduce the issue. We made a change recently (PR1016) to include all columns descriptions so as to align with JDBC 4.3 specifications. For Azure DW this involved constructing a query based on the number of columns in the database which could be rather large and result in this error msg. I have added this to our backlog we will be investigating a possible fix in a later release.

In the mean time, to work around the issue you could call the stored procedure sp_columns_100 manually and work with non JDBC spec compliant columns.

Thank you for bringing this to our attention.

[oleg-mirzaev]

any update on this?
the meaning of this is jdbc getColumns is not working with many columns and we dont know how many columns there might be, we cant use it at all..

[Jeffery-Wasty]

Thank you for the input, we'll take another look at prioritizing this issue.