OPEN_PRC column in data table only returns ints not doubles

cory.schmidt.1

When requesting quarterly/3 month historical data from the Summaries API the data type for the OPEN_PRC column is defined as Int64 which means we're missing data precision for the values. I'm attaching a screen shot of the resulting table...

You can see that the 6 rows in the OPEN_PRC column are all integers.

The code to duplicate the issue...

// Create the platform session.
using ISession session = Sessions.GetSession();

// Open the session
session.Open();

var def = Summaries.Definition()
    .Universe("IBM.N")
    .Interval(Summaries.Interval.P3M)
    .TimestampLabel(Summaries.TimestampLabel.startPeriod)
    .Fields("OPEN_PRC", "HIGH_1", "LOW_1", "TRDPRC_1", "ACVOL_UNS", "NUM_MOVES")
    .Sessions(HistoricalPricing.Sessions.normal)
    .Count(1250)
    .Start("2023-01-02T00:00:00Z")
    .End("2024-05-28T00:00:00Z")
    .GetData();

Common.DisplayTable("Summary for ", dev);

Other instruments do not have the same problem with OPEN_PRC nor do different intervals. Here's a shot of the Visual Studio debugger showing the data type of the OPEN_PRC column...

cristian.baciuwahl

Hello @cory.schmidt.1

I've investigated the issue and there seems a problem with the algorithm deciding the column types.

When data is retrieved from the backend, the first row looks contains an OPEN_PRC value of "190"

Because it is missing precision (it should be "190.00"), this makes the JTokenType for the colum itself to be considered an integer. Afterwards, when creating the data rows, all OPEN_PRC values will be approximated.

I have opened a bug in our backlog and will work towards a fix immediately.

Br,

Cristian

nick.zincone

Hi @cory.schmidt.1

Looking at the result, I can see the first hit (row) does contain an open value represented as an integer - which presumably is mistakenly dictating the column type as an integer as opposed to a float. I can also see subsequent values as floats.

I'll report this to the dev team to investigate - thanks for raising.

cory.schmidt.1

https://community.developers.refinitiv.com/discussion/comment/117680#Comment_117680

I tried loading the new DLLs and am still seeing the same behavior...

Screen shot from the loaded modules list in VS...

cristian.baciuwahl

https://community.developers.refinitiv.com/discussion/comment/117762#Comment_117762

Hello @cory.schmidt.1

Apologies for the mistake!

I tested the BAMS packages in a new console application and it seems that the bug fix is not contained inside them! To remediate the situation I re-created the packages, tested them using a private feed and a console app to double check and redeployed them to BAMS again, then I downloaded the BAMS packages and tested for a 3rd time.

Please download the same version (1.0.7) a second time from BAMS.

Results below from me testing the BAMS packages:

cory.schmidt.1

https://community.developers.refinitiv.com/discussion/comment/117759#Comment_117759

That did the trick. Thanks for the update.