Issue Details (XML | Word | Printable)

Key: CORE-6302
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Tony Whyman
Votes: 1
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Error writing an array of NUMERIC(24,6) to the database

Created: 13/May/20 03:09 PM   Updated: 21/Jul/20 11:17 PM
Component/s: Engine
Affects Version/s: 4.0 Beta 1, 4.0 Beta 2
Fix Version/s: 4.0 RC 1

Environment: Using the FB4 Development Snapshot under Linux Mint 19.3 AMD64

QA Status: Deferred
Test Details:
Deferred until FDB will support new DECFLOAT data type introduced in FB 4.x
Letter from Alex 21.07.2020 23:43


 Description  « Hide
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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 13/May/20 07:01 PM
Tony, can you provide your full test?

Tony Whyman added a comment - 13/May/20 10:27 PM
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.

Alexander Peshkov added a comment - 14/May/20 08:00 AM
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.

Dmitry Yemanov added a comment - 14/May/20 08:07 AM - edited
I see that gen_sdl() inside array.epp is missing the new datatypes. The same is for isc_array_set_desc().

Alexander Peshkov added a comment - 21/Jul/20 01:11 PM
Fixed behavior of Int128 array, now it's as expected, with scale.