Anybody know of any API data feeds that have T&Sales data that include the Flag field for trades. The flag field is a field generated by the exchanges showing whether the trade was 1 - at the ask, 2 - at the bid, 4 - above the ask, 8 below the bid, 16 - inside the spread, 256 and up for formT trades... Typical TSales TRADE (not a quote) data stream structure = stk symbol, date, time, price, size, flag... A lot of API vendors do not even know this field exists or have chosen to ignore it... esignal recognizes this field and includes this flag field in their TS charts in their charting application and in their desktop API which you can program too - but this API is not ready for prime time⦠and is still struggling on its first design legs⦠So I am looking for another API data stream to program too that would have this flag in its data structure
EdgeHunter>esignal recognizes this field ... - but this API is not ready for prime time⦠and is still struggling on its first design legs⦠This sounds interesting. How severe is the "not ready for prime time" situation? i.e. could you get enough usability out of it if you were willing to workaround the deficiencies?
Severe enough that they may only have time to moderately address the deficiences in the Desktop API if they can even get the time to do so since they have higher priorities with their commercial APIs and their larger commercial clients... also add in the costly time it takes to keep their charting application up to date with the latest programming work... They are also thinking/planning that their new API XML data feed might be a better and more efficent way to go then re-design or rebuild the Desktop API handles structure...
OK, you've described the "severity" of the problems in terms of its impact to you, and how eSignal might "workaround" the problems. Could I ask you to describe the nature of these deficiencies? i.e. how does the problem manifest itself? Many years ago, I had a CS professor who said that when we think we've discovered a "bug" in a programming tool because our code doesn't work the way we expect, then we should first go back and take a long hard look at our code. I do realize that in this day and age, that admonition is no longer so universally relevant because compressed dev schedules force dev teams to release s/w before its ready. However, there is still some benefit for considering the old rule of thumb. As such, could you give specific technical examples of how the esignal API is broken? As an aside, how many other datafeed API's have you coded against? Please note that I am not challenging your skill as a programmer. I am merely trying to better understand the severity of deficiencies to see whether it might be worth my time to come up with a workaround sufficient for my purposes. (not saying that my "workaround" would address anyone else's concerns)
*************** The requestHistory function's startTime and EndTime filters don't work and are in the que to be fixed by the API team which acknowlege they don't work. They have been in the que to be fixed or asked by users to be fixed for months. The TSales data gets out of synch when you try to request TS data for more than one stock.... The API team acknowledged this and are working on a fix for next ocx release... the data that comes in duplicates and gets out synch and then repeats, etc The TimeSales handle/filter function was suppposed to also get starttime and endtime filters (promised for 4 months) then decided against by API team because of storage format of TS data... most likely never to be added... no granularity to requests. The API team have stated they are moving away from the idea of trying to further enhance the ocx API and will be focusing those enhancements into the XML data API which may or may not be fully ready in 1-2 (read 3-5 months) The TS function does not work on Win200 - you have to do a minor thing like upgrade to Winxp to use it because of a Ihooks error.... there is more but i am a bit tired...
Ah, OK. Those do seem to be rather severe bugs. With the inability to grab just a subset of the data, then does that mean it's and all or nothing deal? i.e. if you pull any data then you have to pull it all? For instance, if I were willing to download the entire history of a time series and then do the filtering myself, then might that be a possible workaround? As for the duplicate prints, is there a sequence number or some other way of detecting dups such that I'd have something to use to filter them out? I realize such workarounds won't help everyone, but if someone were willing to do this, then could they achieve a usable data set?
Not sure, probably best if you investigated directly... this matix link might be a helpful start... http://www.esignal.com/hubs/matrix.asp
Why NOT use a regular quote datafeed? You don't need a flag to tell you if a price is at the bid/ask or below - a simple compare will do. eSignal and IQFeed both show Form T trades.
Hi J..., eSignal has three servers you can ping with your code... depending on type of data you are trying to get... A real time quote server A real time Time & Sales server A history data server A regular quote datafeed (the esig quote datafeed for us) gives you quotes NOT trades - we found that out when we tried that first... so we went next to their time & sales server which does provide the ability to filter out TS trades from TS quotes but to pull TS data for multiple stocks (in esig) gives problems listed in my posts above... TRUE... like you say - yes you can just compare the last price in a TSale trade against the bid ask values to see if the trade went off at the bid or ask or inside the spread instead of relying on a flag field but the problem is with the data structure of a TSales trade versus a TSales quote... there are no bid ask values in Trade rowsets when you pull the TS data in See this link for xls view of data for TSales data inputs for Intel http://www.enflow.com/samplexls.xls The TS trade rows do not have bid ask values so you have a time consuming and cpu consuming choice if you want to use the bid ask compare route on the TS data... pull both TS trade and quote data into a db table then create an identity seed and do loop backs to grab the just above quote bid ask values to drop them in your trade bid ask value areas(way expensive on cpu if you are trying to do this with 50 stocks every two minutes) or create a self join in a view in SQL server with certain functions to get the bid ask values into the trade rowsets so you can run a compare test then and do this for 50 stocks at a time every two minutes... which is what we ARE going to do but it all would have been so simple if API had just worked the way it was supposed to with the ability to pull multiple stock requests with multiple handles and filter out only the trades and have the flags in them too. simple bada bing... and what we PAID for...
Even I am looking for an API which has flag ( at ask/bid/above ask/below bid ) info from t&sales. Please let me know if you have found one.