question

Upvotes
Accepted
cory.schmidt.1 avatar image
48 ●2 ●4 ●11

OPEN_PRC column in data table only returns ints not doubles

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...

ibmquarterly.png

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...

open-prcint64.png

#technologyhistoricalc#time-seriesrefinitiv-data-libraries
ibmquarterly.png (436.1 KiB)
open-prcint64.png (145.4 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

2 Answers

· Write an Answer
Upvotes
Accepted
cristian.baciuwahl avatar image
237 ●4 ●2 ●3

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

cory.schmidt.1 avatar image cory.schmidt.1

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

1717621025263.png

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

1717621071675.png

1717621025263.png (220.0 KiB)
1717621071675.png (12.9 KiB)
cristian.baciuwahl avatar image cristian.baciuwahl cory.schmidt.1

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:

1717658710971.png


1717658710971.png (103.4 KiB)
cory.schmidt.1 avatar image cory.schmidt.1 cristian.baciuwahl
That did the trick. Thanks for the update.
Upvotes
nick.zincone avatar image
19k ●85 ●39 ●63

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.