500 symbol limit

[LH779]

Hi, I am writing programs to retrieve historical data for about 10000 symbols. I was told it is ok for the 500 symbol limit desktop API if the program is just to store data into the database. Currently my problem is everytime after sending six requests for total 600 symbols, I have to manually stop the program to remove those symbols from the eSignal's data manager, then restart the program to get more. I am looking for a way to automate.

What I did was the following,
1. send 100 symbol requests.
2. after receiving the data, call esignal.ReleaseSymbol(symbol), esignal.ReleaseHistory(lHandle) in onBarsReceived(Changed).
3. if without getting data for 10 minutes (as one user pointed out in another thread the program does not get historical data for some symbols promptly), call esignal.ClearSymbolCache(), esignal.ReleaseAllHistory(), esignal.ReleaseAllTimeSales()
4.Thread sleep for 5 minutes
5. repeat step 1: send another 100 symbol request

Although the program calls eSignal's release and clear calls, it seems that the data manager still keeps track of some of the symbols (not all of them, some have gotten the data and some not). I have to manually stop the program and delete these symbols from the data manager before asking for more symbols, otherwise the symbol limit error will pop up.

Restart eSignal doesn't help either. The symbols are still in the data manager.

I am pretty new to eSignal, and I was wondering if there is another way to do this.

Thanks.

Lu

[Guest]

Yes, there is a function called "ClearSymbolCache()" that will clear all symbols in the Data Manager. That should be what you are looking for.

[LH779]

I used that call (step1 and 3 in my previous post) at the initial eSignal set up, then everytime before sending a group of new requests, but it didn't work. Some of the symbols are still in the data manager.

[wscully]

500 Symbol limit problems

I also was frustrated by the data manager symbol count increasing in spite of releasing the cache. I finally found a code sequence that works and keeps the symbol count low.

I have attached a code example written in VB.Net.

If my example is not helpful, feel free to call me at my home (574-247-5558) during the day.

Bill Scully

[wscully]

500 Symbol limit problems

I also was frustrated by the data manager symbol count increasing in spite of releasing the cache. I finally found a code sequence that works and keeps the symbol count low.

I have attached a code example written in VB.Net.

If my example is not helpful, feel free to call me at my home (574-247-5558) during the day.

Bill Scully

[GenSpoo]

Are you sure you really want to give out your home number on an open Internet forum? People can always PM you if they have questions and then you can give them your number if you need to talk.

Cheers... George

[Guest]

As far as I can tell in this code snippet, it calls GetBasicQuote outside of OnQuoteChanged, which should not be done, as described in this thread:

http://forum.esignalcentral.com/showthread.php?s=&threadid=11297

[wscully]

Robi, it does not call GetBAsicQuote; I do that inside of the event handler. It does call XMLGetBasicQuote, which seems to be analagous to RequestSymbol. LoadXML() seems to be the analog of GetBasicQuote. I originally had XMLGetBasicQuote within the event handler and had a lot of problems. It has been smoother going since I adopted this approach.

[wscully]

Robi, it does not call GetBAsicQuote; I do that inside of the event handler. It does call XMLGetBasicQuote, which seems to be analagous to RequestSymbol. LoadXML() seems to be the analog of GetBasicQuote. I originally had XMLGetBasicQuote within the event handler and had a lot of problems. It has been smoother going since I adopted this approach.

[Guest]

You can technically call these functions outside of the event handler, but some developers are running multi-threaded applications were making these calls outside of it which can cause critical errors.

[wscully]

500 Symbol Limit

Robi, I have followed your suggestion. I start a stock symbol and associated call and put call sequence by issuing the initial GetBasicQuote in my main thread; I issue all following GetBasicQuote, XMLGetBAsicQuote, and XMLGetFundamentalData function calls within the handler thread. This seems to work fine.

[LH779]

Thank you Bill. Also thanks Robi.

I'll try the code.

[wscully]

500 Symbol limit

I have attached a section of my code to show you how I am dealing with eSignal. After a lot of trial and error (a lot of errors) testing I have found that the following sequence works best, but not perfectly. eSignal will still stall (not enter event handler after a request which makes me wait until I timeout) or crash but this is a lot better than what I experienced before. You can, of course, improve upon my coding (I am an old mainframe assembler language programmer:-) ). The key for me was to allow the event handler thread to finish before my mainline continued after asking for data from eSignal - I definitely did not want to use timed waits to restart mainline processing - wastes time and makes assumption that eSignal finished in time allotted.

Basically what I do is this:

My mainline starts the request with RequestSymbol for the stock in question followed by a Wait (which will be posted in event handler or timeout after two seconds).

The eventhandler processes the event for the initial RequestSymbol and issues subsequent Request Symbols and events for the specific Call and Put symbols that I am interested in as well as issuing the XML requests and handling the responses.

This sequence works most of the time. As I noted earlier, eSignal sometimes will stall after a RequestSymbol request and also crashes with "The instruction at 0x5ad71531 referenced memory at 0x00000014.' The memory could not be "Read."

But, all in all, when it works, the results are very helpful to me.

Good luck,
Bill

[Guest]

Bill, can you send an .exe that causes this crash? Then, Dion will be able to run it in a debugger to see if it is an obvious problem and may be able to correct it quickly.

It think it is hitting the same memory location as Jim's crash in the other thread.

[JimBecker17]

Just replied on the other thread. Glad you guys are looking at this. Yes, it's the same crash. It's an asynchronous thing, and those can be pretty tough to track down and resolve. Thanks for working on it.

BTW I am not doing RequestSymbol() or XML*() in my logic, so this error is somewhat independent of the actual routine. Sounds like a message being processed to delete an object when it should be deferred or something.

-Jim