question

Upvotes
Accepted
791 9 7 14

Publications on TREP via Eikon Excel

Is anyone aware of what would cause a NAK error when publishing to BID field a value like this 1.123456789 and yet it works fine with 1.12345678 when publishing to an internal source defined on ADH?

I don’t see any restrictions as far as the BID Field is defined in the data dictionaries on TREP.

elektronrefinitiv-realtimetreprfaADH
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
301 6 17 27

I did some test recently around this area and it appeared to be that Eikon Excel has limitations when it comes to Posting a value with more than 8 decimal places. Wrote some code in RFA Java OMM and was able to Post up to 14 decimal places without any problems and I could consume that record just fine in Eikon and standard RFA consumer application without any issues.

Populate FID 25 : ASK with Real 0.00000000000001 to 14 decimal places (EXPONENT_NEG14) value = 0.00000000000001; longValue = Rounding.roundDouble2Long(value, OMMNumeric.EXPONENT_NEG14); _postOMMEncoder.encodeFieldEntryInit((short)25, OMMTypes.REAL); _postOMMEncoder.encodeReal(longValue, OMMNumeric.EXPONENT_NEG14);

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.

Click below to post an Idea Post Idea