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
Error writing an array of NUMERIC(24,6) to the database [CORE6302] #6544
Comments
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Commented by: @AlexPeshkoff Tony, can you provide your full test? |
Commented by: Tony Whyman (twhyman) Alex, I started preparing a detailed response and in going through the code, I decided to try a variation on the SDL generation. I had assumed that blr_int128 would behave the same as blr_short,blr_long, blr_int64, and blr_quad and require that a scale was included in the SDL Block. In one last attempt to make it work, I commented out the line that added the scale factor for blr_int128, recompiled the test - and it worked. In the end, the problem is lack of documentation and that I hadn't tried all possible combinations. The bug should now be closed - but at least anyone else who falls into the same trap will find this report when they google it. |
Commented by: @AlexPeshkoff The bug should not be closed - certainly your initial assumption about SDL (scale should be present) is right. But something goes wrong with SDL parser. |
Commented by: @dyemanov I see that gen_sdl() inside array.epp is missing the new datatypes. The same is for isc_array_set_desc(). |
Modified by: @dyemanovVersion: 4.0 Beta 2 [ 10888 ] |
Modified by: @dyemanovsummary: Error writing an array of NUMERIC(24,6) to the database when using FB4 Development Snapshot => Error writing an array of NUMERIC(24,6) to the database |
Modified by: @AlexPeshkoff |
Commented by: @AlexPeshkoff Fixed behavior of Int128 array, now it's as expected, with scale. |
Modified by: @AlexPeshkoffstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 RC 1 [ 10930 ] |
Modified by: @AlexPeshkoff |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Deferred Test Details: Deferred until FDB will support new DECFLOAT data type introduced in FB 4.x |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] Test Details: Deferred until FDB will support new DECFLOAT data type introduced in FB 4.x => Deferred until FDB will support new DECFLOAT data type introduced in FB 4.x |
Submitted by: Tony Whyman (twhyman)
Votes: 1
I have created a table as follows in order to test out FB4 array handling with the new datatypes.
Create Table FB4TestData_DECFloat_AR
RowID Integer not null,
Float16 DecFloat(16) [0:16],
Float34 DecFloat(34) [0:16],
BigNumber NUMERIC(24,6) [0:16],
Primary Key(RowID)
);
The metadata indicates that the first two arrays are arrays of DecFloat(16) and DecFloat(34) respectively, while the latter is an INT128 array with a scale factor of -6.
Running separate tests on each array column: the first two perform as expected with both read and write operations successful and the read results corresponding to the write. However, the "putslice" API method fails when writing the NUMERIC(24,6) array type with the error message:
column not array or invalid dimensions (expected 0, encountered 1).
The SDL for the putslice is the same as for the Float34 array except for the data type and scale factor. The SDL is generated following src/yvalve/array.epp
Commits: 6ddbea6
====== Test Details ======
Deferred until FDB will support new DECFLOAT data type introduced in FB 4.x
Letter from Alex 21.07.2020 23:43
The text was updated successfully, but these errors were encountered: