I'm requesting for TR.ISIN and TR.SEDOL for instrument list of 1700 items.
It works fine, but I see some strange tickers returned :
There are about 20 of them. There are COL.SN, EEM.SN and ENJ.SN in the instrument list and in the results. But what are those with the "/" ?
Thanks
@igorg
While DEX2 library does not retrieve any real-time market data, the Web service behind it has the capability to expand chains using real-time datafeed. Two of the symbols you mentioned (.PG.SN and .PL.SN) are chains of top percent gainers and losers on Santiago Stock Exchange. These are dynamic chains whose constituents are updated throughout the day. When the Web service expands the chain, it enforces real-time data entitlements. Since your Eikon account is not entitled for real-time data from Santiago Stock Exchange, you get back delayed RICs. I'm going to take a guess and say that the inclusion of .PG.SN, .PL.SN and .TM.SN symbols in your list is probably not intentional. Perhaps you got these symbols from the search and didn't filter them out from the search results?
/ in front of the RIC name usually signifies a delayed data RIC. This happens when you do not have access to the real-time data (for example, EEM.SN), so the system will give you back /EEM.SN.
If the user that is running your app has access, they will receive a RIC without the /.
But dex2 is not real-time data...
Also SEDOL and ISIN are not real-time fields..
Also I use the same user as always.
i do not think it matters which API you use in order to get a delayed RIC instead of a normal one, as the permission database is the same.
I just checked.. I receive 2 lines:
1. with / and NULL for other fields
2. without / and with some values for other fields which look correct
Try Instrument list :
.PG.SN,.PL.SN,.TM.SN
Field list:
TR.SEDOL;TR.ISIN;TR.RIC
Display parameters:
RH:In
I'm expecting RIC in the first column because of "RH:In"
Result:
/LVCORA.SN NULL NULL NULL /EWZ.SN NULL NULL NULL /NOR.SN NULL NULL NULL /SAAM.SN NULL NULL NULL /PEH.SN NULL NULL NULL /ENJ.SN NULL NULL NULL /LAP_r.SN NULL NULL NULL /SEC.SN NULL NULL NULL /COL.SN NULL NULL NULL /TRC.SN NULL NULL NULL /SIX.SN NULL NULL NULL /IAN.SN NULL NULL NULL /EEM.SN NULL NULL NULL /ACWI.SN NULL NULL NULL /ENT.SN NULL NULL NULL /BTGEU.SN NULL NULL NULL /ORO.SN NULL NULL NULL ......
Your guess is correct. And I'm going to filter them out sooner or later..
My concern is more about unclear (non-consistent) behavior of dex2 mananger:
1. If use RH:In in display parameters, I get those RICs
2. If I don't use RH:In, but add TR.RIC to requested fields, I do not get those RICs.
Honestly, I expected the same result, but it's not.
This inconsistent and admittedly not very intuitive behavior is by design. The relatively rare use case of expanding a chain was never meant to be mixed with the popular use case of retrieving a list of fields for a list of RICs. The capability to expand a chain was retrofitted as a special and standalone use case into the interface designed to return a list of fields for a list of instruments.
Unfortunately in this scenario a level of inconsistency is unavoidable. E.g. when you include TR.RIC field with a chain RIC is it reasonable to assume that you are asking for the RICs for chain constituents or that you're asking for the chain itself? Because .PG.SN is also a RIC.
I'm new to finance area and still missing some knowledge... But it makes sense. And since I have a way to filter them out, it's not a problem.
