Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)




"As a past ******* customer(and not a happy one), IQ Feed by DTN is a much better and cheaper product with great customer support. I have had no problems at all since switching over." - Comment from Public Forum
"I have to tell you though that using the IQFeed API is about the easiest and cleanest I have seen for some time." - Comment from Jim
"I am very pleased with the DTNIQ system for quotes and news." - Comment from Larry
"I just wanted to let you know how fast and easy I found it to integrate IQFeed into our existing Java code using your JNI client. In my experience, such things almost never go so smoothly - great job!" - Comment from Nate
"I'm very glad I switched to IQFeed. It's working perfectly with no lag, even during fast market conditions." - Comment from Andy via Email
"Just a thank you for the very helpful and prompt assistance and services. You provided me with noticeably superior service in my setup compared to a couple of other options I had looked at." - Comment from John
"Thanks for all of your help. Great customer service deserves to be recognized which one the reasons I've been a customer of DTN for over 10 years!" - Comment from Stuart
"If someone needs the best quality data and backfill beyond what their broker provides at a rate that is the best in the industry, I highly recommend IQFeed." - Comment from Josh via Public Forum
"You have an excellent feed. Very few spikes for Spot Forex." - Comment from Public Forum Post
"I will tell others who want to go into trading that DTN ProphetX is an invaluable tool, I don't think anyone can trade without it..." - Comment from Luther
Home  Search  Register  Login  Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
Follow DTNMarkets on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
»Forums Index »Archive (2017 and earlier) »IQFeed Developer Support »HM History command
Author Topic: HM History command (10 messages, Page 1 of 1)

stargrazer
-DTN Guru-
Posts: 302
Joined: Jun 13, 2005

Right Here & Now


Posted: Jan 7, 2006 07:08 PM          Msg. 1 of 10
When telnetting and trying:

HM,CSCO,1,1;

today, I get the following response:

HM,CSCO,1,1;!ERROR! !NONE!

!ENDMSG!
!ERROR! Unknown Error.

!ENDMSG!

A couple of issues:
a) Is the !NONE! error correct in that there is no data for today (Saturday)? My buffer handling logic handles the situation ok, I just wanted to be sure the '1 day' selected is for the current day rather than the latest trading day. Is that what the day counts mean--calendar day count rather than trading day count?
b) There is a second error set starting with '!ERROR! Unknown Error.'. This second error destroys my buffer state machines because it is not an expected response. Is it meant to be, or can it be removed?

An 'HM,CSCO,2,1;' works as expected.

DTN_Jay_Froscheiser
-VP, Product Operations-
Posts: 1746
Joined: May 3, 2004

DTN IQFeed/DTN.IQ/DTN NxCore


Posted: Jan 7, 2006 07:14 PM          Msg. 2 of 10
a) Yes, everything in IQFeed is calendar days, so requesting 1 day is going to give you today as opposed to the last trading day. This makes things a bit easier when dealing with international issues or other contracts such as the emini which starts trading on Sunday.

b) Will have to see what the developers have to say on Monday on this one...

Jay Froscheiser
DTN - Trading Markets

DTN_Steve_S
-DTN Guru-
Posts: 2093
Joined: Nov 21, 2005


Posted: Jan 23, 2006 09:54 AM          Msg. 3 of 10
b) I hadn't been able to duplicate this until this morning. I believe I know what is causing it and this should be fixed in an upcomming release.

Edited by DTN_Steve_S on Jan 23, 2006 at 01:23 PM

FullyArticulate
-DTN Guru-
Posts: 332
Joined: Sep 22, 2005


Posted: Jan 23, 2006 12:13 PM          Msg. 4 of 10
Quote:
Yes, everything in IQFeed is calendar days, so requesting 1 day is going to give you today as opposed to the last trading day. This makes things a bit easier when dealing with international issues or other contracts such as the emini which starts trading on Sunday.


I wish that were true, but it's inconsistent. HM is in calendar days, HD is in trading days. In other words, on Sunday, if you request HD for 1 day, you get Friday's history. If you request HM for 1 day, you get an error.
Edited by FullyArticulate on Jan 23, 2006 at 12:14 PM

David
-DTN Evangelist-
Posts: 113
Joined: May 7, 2004

I'd rather be...


Posted: Jan 23, 2006 03:25 PM          Msg. 5 of 10
FWIW: I would like to see the weekend logic for historical data be 'corrected'. A request for one day of data should reflect the last trading days data regardless if requested on a weekend, holiday or during open market hours. In the case of thinly traded issues it may have to go back in time even on market days to get the data. I know that the history for the current daily data only shows after market close, however this is a special case.

Thanks!

David

IQXP Software
http://www.iqxp.com

LiveWire Update Service
PO Box 1417
Fairfield, IA 52556
641-472-8393
http://www.livewire-cablesoft.com/

taa_dtn
-DTN Evangelist-
Posts: 154
Joined: May 7, 2004


Posted: Jan 24, 2006 12:00 PM          Msg. 6 of 10
I think the best approach would be to request historical data starting from a given feed date and time and ending just before a given feed date and time, rather than N days previously or N trading days previously. That eliminates the ambiguities around midnight (local time and feed time) and eliminates the need for client apps to understand weekly trading schedules and holidays. It also permits partial-day history requests during the day and gap-filling history requests that don't have to run all the way to the current day (should you ever want to support such features).

And for what it's worth, returning historical data from most-recent to least-recent seems wrong to me. In general apps are designed to handle streamed data, which always arrives in chronological order. For history requests that return data in reverse chronological order you just have to soak up the entire history and reverse it before you can apply the same logic that you use for streamed data -- and that's typically what you want to do for back-testing or generating context for watching a symbol for the first time. Finally, from the point of view of consistency, it's odd that if you request one day's worth of history on each of two successive days, the data you get isn't the same as if you request two days worth of history at the end of the second day. It's in a different order.

Allen

KDE
-Interested User-
Posts: 4
Joined: Jan 25, 2006


Posted: Jan 25, 2006 07:13 AM          Msg. 7 of 10
To IQFeed support team:
Please respond about a second "!ERROR!" section after "!NONE!". My client application doesn't wait for it, because the API reference says that the answer should finish with "!\r\nENDMSG!\r\n" string. So when I receive

!ERROR! !NONE!



!ENDMSG!

, I expect this to be the end of the answer, and finish data retrieval procedure.
And when the next request to IQFeed is processed (with other symbol name), I receive the

!ERROR! Unknown Error.



!ENDMSG!

responce, that was left from the previous request. Thus, all further work crushes, because I start processing previous answers instead of current ones.

Please respond if this is a bug, or how do you propose to handle this situation on the client side.

Thank you.

DTN_Steve_S
-DTN Guru-
Posts: 2093
Joined: Nov 21, 2005


Posted: Jan 25, 2006 08:30 AM          Msg. 8 of 10
This is a bug. It will be fixed in an upcomming release (unfortunatly it is probably too late to include it in the current release that is being tested).

In my experience, it is fairly predictable when this will happen. It only seems to affect HM and HT socket requests. However, any History request that produces the !ERROR! !NONE! would also produce the second unknown error as well.
Edited by DTN_Steve_S on Jan 25, 2006 at 08:31 AM

KDE
-Interested User-
Posts: 4
Joined: Jan 25, 2006


Posted: Feb 9, 2006 08:18 AM          Msg. 9 of 10
Hello.
I just downloaded the new IQFeed release 4.1.1.1.
It seems that the mentioned bug is still there. There're still 2 error messages returned in response to a request with an incorrect symbol name. However, the text of the 2nd error message has changed from "Unknown error" to "Incorrect symbol".

I was hoping that there would be only one error message - "Incorrect symbol", not two. Is it really necessary to send that "!NONE!" error message first? Because of this "!NONE!" message I'm forced to update my client software for the 2nd time for a month.

Hopefully, this situation will be resolved once and for all.

Regards, KDE

DTN_Steve_S
-DTN Guru-
Posts: 2093
Joined: Nov 21, 2005


Posted: Feb 9, 2006 08:43 AM          Msg. 10 of 10
Hello KDE, I appologise for the delay in releasing a fix for this issue. I had mentioned in my previous post that the fix would probably not make this release. We are tenativly planning a small maintanence release that will take care of this as well as a couple other issues that have been brought up since the release of 4.1.1.1.

On the other hand, you seem to be having a slightly different problem. I am still only returning the Unknown error as the 2nd error.

Here is the way it should work.
The None error response is sent only when a symbol returns no data.
The Invalid symbol error is sent only when the Symbol requested is not found.


Can you post what you were requesting in order to get the None error followed by an Invalid Symbol error?
 

 

Time: Sun May 5, 2024 4:58 PM CFBB v1.2.0 12 ms.
© AderSoftware 2002-2003