Announcement

Collapse
No announcement yet.

No bid/ask in history request

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • No bid/ask in history request

    The BarData structure returned by the RequestHistory function has bfFlags, dTickBid, and dTickAsk fields, but these fields are always zero. I have tried all possible variations in the "interval" parameter, and the results are always the same.

    Is there some parameter not listed in the documentation that will fill in the missing data fields?

  • #2
    At the moment, we are looking into this.

    As an alternative, you can obtain bid/ask/trade data by using the
    Time and Sales function of the Desktop API. Please consult
    the Desktop API documentation regarding its usage.

    Anthony

    Comment


    • #3
      Unfortunately, the Time and Sales function only returns a maximum of 10 days of data, which isn't a big enough data window for my application.

      Comment


      • #4
        If you want to obtain raw tick data using the timesales
        function, the maximum number of tick data you can get is 10 days.

        On a separate note, if you want to obtain non-zero
        bfFlags, dTickBid, dTickAsk, dTickTrade using requestHistory, you can set interval to "T". Give that a try.

        Anthony

        Comment


        • #5
          Yes, setting the interval parameter to "T" does return the bid, ask, and flags fields, but as I'm sure you're aware, the "T" interval makes it a request for tick data.

          I had been requesting a 5 minute interval for the entire history available to chart stocks I haven't been actively tracking. Running a sample using the symbol AMD, I receive 9,358 bars of data for the 5 minute interval. By requesting tick data, the number of bars jumps to 649,773. That's 70 times the amount of data, which is a massive increase of the load on your servers, and a corresponding decrease in my program's ability to display a chart in a reasonable amount of time.

          Since your computers are obviously storing the data as ticks, and history requests must be extracted as snapshots at a given interval, I don't understand why some data wouldn't be included in the returned bars for intervals other than tick. It would take very few(if any) cpu cycles to return all the data, and the bandwidth used is the same to return the true data as to return zeros.

          Comment


          • #6
            What is the exact function call and argument you run to
            get 9,358 bars of data for AMD vs 649,773 bars of tick data?

            I am assuming that your charting application does need the tick data (bid/ask/trade) info. How many days of data are you requesting afterall?

            Comment


            • #7
              What is the exact function call and argument you run to
              get 9,358 bars of data for AMD vs 649,773 bars of tick data?
              To get 5 minute interval data:
              lHistoryHandle = esignal.RequestHistory("AMD", "5", btDAYS, 200, -1, -1)
              To get tick data:
              lHistoryHandle = esignal.RequestHistory("AMD", "T", btDAYS, 200, -1, -1)
              I am assuming that your charting application does need the tick data (bid/ask/trade) info.
              Yes, I need the bid/ask/price. No I don't need tick data. At any point in time there is not only a current price, volume, etc. but also a bid and ask. My question concerns the lack of the bid and ask values in the data records(bars) returned following a history request if the interval is other than tick.
              How many days of data are you requesting afterall?
              As I said in my previous post, all available history. In the Developer Reference Guide, under "Making a History Request" section, there is an example where the value 200 is used for the number of days. When I was getting started, I just used this value. In reality, only 120 days are returned for any history data request with an interval other than day.

              By only returning valid bid/ask data when the interval is "tick", any user who wants to retrieve bid/ask for other intervals is forced to use the "tick" interval and then extract the bid/ask for the requested interval. That substantially, and unnecessarily increases the load on the servers. The load increase is most obvious in my circumstance, but for any other interval the same ratio of wasted bandwidth would apply.

              Comment


              • #8
                Thank you for your information. Unfortunately, to obtain historical bid/ask/trade information, you will have to use the "T" interval with the requestHistory function. This goes to the tick server to obtain data. Or you can use the timesales functions.
                You can use the bfFlags to do further filtering if needed.

                Please change your data request from 200 days to 120 days. We keep up to 120 days of historical bar data on our history and tick servers. We will update our documentation and thank you for pointing it out.

                Anthony

                Comment


                • #9
                  A slight correction to my previous posting. We do keep up to 120 days of "intraday" data on our history and tick servers. The documentation is correct because it was referring to getting
                  200 historic daily bar, not intraday data.

                  For your calls:
                  esignal.RequestHistory("AMD", "5", btDAYS, 200, -1, -1)
                  esignal.RequestHistory("AMD", "T", btDAYS, 200, -1, -1)

                  Both pertains to getting intraday data and it's well over 120 days.

                  Anthony

                  Comment

                  Working...
                  X