For a deeper look into our Eikon Data API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
igorg avatar image
646 ●6 ●13 ●25

Different results for the same query

3 requests:

1. ek.get_data('0#IPC:', ['RECORDTYPE'], '')

2019-03-15 16:45:14,189 -- pyeikon -- DEBUG -- Request:{'Entity': {'E': 'DataGrid', 'W': {'instruments': ['0#IPC:'], 'fields': [{'name': 'RECORDTYPE'}]}}, 'ID': '123'} 
2019-03-15 16:45:15,220 -- pyeikon -- DEBUG -- HTTP Response code: 200 
2019-03-15 16:45:15,220 -- pyeikon -- DEBUG -- HTTP Response: {"columnHeadersCount":1,"data":[["/IPCM9",114],["/IPCU9",114],["/IPCZ9",114],["/IPCH0",null]],"error":[{"code":251658243,"col":1,"message":"'The record could not be found' for the instrument '/IPCH0'","row":3}],"headerOrientation":"horizontal","headers":[[{"displayName":"Instrument"},{"displayName":"RECORDTYPE","field":"RECORDTYPE"}]],"rowHeadersCount":1,"totalColumnsCount":2,"totalRowsCount":5}

The program skipped /IPCH0 as invalid ticker

2. ek.get_data('0#IPC:', ['RECORDTYPE'], '')

2019-03-15 17:07:16,584 -- pyeikon -- DEBUG -- Request:{'Entity': {'E': 'DataGrid', 'W': {'instruments': ['0#IPC:'], 'fields': [{'name': 'RECORDTYPE'}]}}} 
2019-03-15 17:07:17,713 -- pyeikon -- DEBUG -- HTTP Response code: 200 
2019-03-15 17:07:17,713 -- pyeikon -- DEBUG -- HTTP Response: {"columnHeadersCount":1,"data":[["/IPCM9",114],["/IPCU9",114],["/IPCZ9",114],["/IPCH0",114]],"headerOrientation":"horizontal","headers":[[{"displayName":"Instrument"},{"displayName":"RECORDTYPE","field":"RECORDTYPE"}]],"rowHeadersCount":1,"totalColumnsCount":2,"totalRowsCount":5}

The program assumed that /IPCH0 is valid ticker.

Next request :

ek.get_timeseries('/IPCH0', ['VOLUME;VALUE','TIMESTAMP'], '2019-03-15T00:00:00', '2019-03-15T00:00:01', 'daily')

2019-03-15 17:08:17,103 -- pyeikon -- DEBUG -- Request:{'Entity': {'E': 'TimeSeries', 'W': {'rics': ['IPCH0'], 'fields': ['VOLUME;OPEN;CLOSE;HIGH;LOW;', 'TIMESTAMP'], 'interval': 'daily', 'startdate': '2019-03-15T00:00:00', 'enddate': '2019-03-15T00:00:01'}}} 
2019-03-15 17:08:17,731 -- pyeikon -- DEBUG -- HTTP Response code: 200 
2019-03-15 17:08:17,731 -- pyeikon -- DEBUG -- HTTP Response: {"timeseriesData":[{"dataPoints":null,"errorCode":"TSIError","errorMessage":"Error: TSINotPermissioned, ErrorCode: TA-TSINotPermissioned, Fault: TSIError, Description: The user does not have permission for the requested data","ric":"IPCH0","statusCode":"Error"}]} 
2019-03-15 17:08:17,731 -- pyeikon -- WARNING -- Error with IPCH0: The user does not have permission for the requested data 
2019-03-15 17:08:17,731 -- pyeikon -- ERROR -- IPCH0: The user does not have permission for the requested data |

The program stopped as not-expected error come.

3. The same steps as in #2, but in the second request we get expected result:

>>> ek.get_timeseries('/IPCH0', ['VOLUME;VALUE','TIMESTAMP'], '2019-03-15T00:00:00', '2019-03-15T00:00:01', 'daily')
Error with /IPCH0: No data available for the requested date range
/IPCH0: No data available for the requested date range |
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files (x86)\Python37-32\Lib\site-packages\eikon\time_series.py", line 193, in get_timeseries
    raise EikonError(-1, message=ts_error_messages)
eikon.eikonError.EikonError: Error code -1 | /IPCH0: No data available for the requested date range |

As you can see, 3 different results for the same ticker within 30-35 minutes. We handle 1st and 3rd scenarios. But "The user does not have permissions.." for the ticker that we just collected from Chain request looks strange.

Any possible explanation of this behavior ?

eikoneikon-data-apiworkspaceworkspace-data-apirefinitiv-dataplatform-eikonpython
icon clock
10 |1500

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

1 Answer

Upvotes
Accepted
Alex Putkov.1 avatar image
39.2k ●75 ●11 ●27

I think it is related to the rollover that happens today for this future. IPCH9 expires today. It must have been removed from the chain after market close, and a new contract IPCH0 was added. This operation does not happen at the exact same moment on all backend systems, which is why you see this rather confusing behavior. It seems that the first time you requested data the real-time chain 0#IPC: already had RIC IPCH9 removed and IPCH0 added. But the delayed RIC /IPCH0 may not have been created yet, which is why you got null as the value of the RECORDTYPE field. Similarly when you requested timeseries for IPCH0 you got not permissioned error because you're not entitled to real-time data for this future and the delayed RIC was probably not yet created on the timeseries database.
You may want to adjust the time when you run the requests to accommodate for the rollover process. It may also be helpful to request delayed data explicitly rather than letting the system to fall back on it.
By the way with your current process you're missing the quotes for IPCH9, which was still trading today.

icon clock
10 |1500

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

igorg avatar image igorg

It makes sense.

And thank you for the hint about missing data in our process.

Click below to post an Idea Post Idea