Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong FBResultSetMetaData.getPrecision() on "computed by" columns [JDBC450] #490

Closed
firebird-automations opened this issue Aug 31, 2016 · 9 comments

Comments

@firebird-automations
Copy link

Submitted by: Honza Hubeny (hubeny)

Let's have table in firebird database

create table TEST (
A NUMERIC(15,3)
B NUMERIC(15,3)
C computed by (A+B)
)

than when wi have Java code:
Connection conn;
...
PreparedStatement statement = conn.prepareStatement ("select * from TEST");
ResultSet retVal = statement.executeQuery();
FBResultSetMetaData metaData = (FBResultSetMetaData) sqlResultSet.getMetaData();
int i = index of C column;
//This column returns ZERO
metaData.getPrecision(i);

Commits: 4b5972d 8e65d7f

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

What is the dialect of your database?

@firebird-automations
Copy link
Author

Commented by: Honza Hubeny (hubeny)

We have following parameters in the connection string:

dialect=3&encoding=UTF8&defaultHoldable=true&columnLabelForName=true

Therefore sql dialect is 3.

Further comment to java code:
for Columns A and B
metaData.getPrecision(i); // returns 15
metaData.getScale(i); // returns 3

for column C
metaData.getPrecision(i); // returns 0
metaData.getScale(i); // returns 3

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

The caused by a bug in Firebird 2.5, which has been fixed in Firebird 3. The problem is that Firebird 2.5 reports the field as precision 0; you can see this for yourself in RDB$FIELDS, eg using: select * from RDB$FIELDS where RDB$COMPUTED_SOURCE = '(A+B)'.

I can probably work around this problem by 'estimating' the precision if it is reported as zero; the estimated precision would be 19 (and not 18).

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2.12 [ 10781 ]

Fix Version: Jaybird 3.0 [ 10440 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Version: Jaybird 3.0.0-alpha-1 [ 10780 ]

@firebird-automations
Copy link
Author

Commented by: Honza Hubeny (hubeny)

We made a similar workaround directly in our Java application too. I must appologize that I did not explore this bug in deep before reporting it. I did not check whether it is correct in firebird system tables.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Fixed for 2.2.12 and 3.0. The estimate for 2.2.12 will be 19, for 3.0 it will be 18 (which is more correct).

The primary reason to use 19 in 2.2.12 is that we already estimated the precision in some cases and that used 19; changing it to 18 would have been a (potentially) breaking change which I didn't want to do in a point release. This estimation had already been revised to 18 in 3.0.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment