HistoricalPricing events return incorrect data table column types using beta 5 library.

Since beta 5 of the RDP library for .net the resulting DataTable of HistoricalPricing.Events requests has no valid column types set. This was working in previous version. In the beta 5 all column types are set to "System.Object".

I reproduced this using the example 2.1.02-HistoricalPricing-Events using "Workspace" application. Looking at the json response the header types are correct, but they are just not set on the DataTable.

Inserting the following line can test this case:

//check if all columns are specified as "System.Object"
Debug.Assert(response.Data.Table.Columns.OfType<System.Data.DataColumn>()
.Where(col => col.DataType == typeof(object)).Count() == response.Data.Table.Columns.Count);

Find more posts tagged with

.net

refinitiv-dataplatform-libraries

#technology

Accepted answers

nick.zincone

Hi @martin.grunwald,

The intention of defining the column type: System.Object was because it is possible that values within the column can be null (DBNull.Value). However, the values within the cells are represented by their native type, i.e. string, float, integer, etc. Through more research, I discovered that despite defining a column type of string or float, the value null is permissible. While the header details within a response carry 'type' information, it isn't necessarily granular, i.e. 'number' could be integer or float. We can attempt to provide more fine-grained types though interrogation. Not to mention, not all endpoints carry type information.

For the next release, what we can do is define the column type based on the data defined within the cells. However, it is possible that all rows within a column may contain null and that defining the column type to 'System.Object' may be the most appropriate result.

All comments

nick.zincone

Hi @martin.grunwald,

martin.grunwald

Thank you for the answer. I am not sure I have the time to wait for a new release I may have to rewrite my code to not rely on the column types being set. I can probably deduce the type by looking at the row values that are not DBNull.

EXPLORE OUR SITES