Subscript out of range. You must not access array elements outside 0..(BarCount-1) range. Occurs when you attempt to access array elements with subscripts below 0 (zero) or above BarCount-1.
So first of all, you should make sure, that your code is protected against producing this error. Forcing AmiBroker to repeat a possibly faulty code is not a solution. Here you can find some possible ways of resolving this issue:
Is it possible to see right away which symbol produces this error in Exploration? When I have 300 symbols and this happens to 1, it becomes difficult to find the problem. All I get is the just the Error, but not which symbol causes it.
This is not the most important issue, because as you can read in the explanation of "Subscript out of range Error" - your code should be protected against producing such errors and should work properly no matter if the stock's barcount is 5 or 5K or 5M.
No, you can't because eSignal (and other RT vendors too) terms and conditions specifically disallow doing repeated backfill requests automatically. By their rules such resource consuming actions need to be triggered only manually.
In addition to what Tomasz wrote: If you want to scan live market being connected via plugin, you should start your session from doing a pre scan (or pre exploration) allowing AmiBroker to subscribe all necessary issues (and give some time to download the data). Usually when AmiBroker is downloading lots of data, the plugin Status area changes color and is flashing. When the download/update is finished and everything is OK, it changes color to green.
You should wait for that before running next scans/explorations. This first scan or exploration usually takes some time, but the following ones should be performed much quicker.
I additionally recommend reading this:
You can also find lots of useful information and tips (regarding this topic) in this article:
There is another thing that you should check. The fact that you get few bars suggests that your database is not saving PREVIOUSLY backfilled data. In File->Database Settings you must have "local data storage" enabled. This is crucial to have it turned ON.
If it is enabled, and software is registered so data are stored on disk, then all previously backfilled data (i.e. from PREVIOUS days) are already in the database and there is practically NO chance that you would have "too few bars" because you would always have data from previous days.
If you randomly get errors and randomly lose data then something may be wrong with the computer/harddisk.
Overall the systen is reliable as this error occurs about twice a week of nonstop operation, but it essentially stops everything when it does. I strongly believe it is becase of rare connection issues with eSignal. I cannot automatically do a force backfill nor see which symbol causes the problem and it takes ages to sort through all symbols to find the cause.
... but if the reason of these problems is as you suggest: rare connection issues with eSignal, it doesn't matter which symbols were the last one processed. I won't speculate further, because I have no experience with eSignal.
Thanks @Milosz! Tried the Trace method, but this doesn’t help much unfortunately when MultiThreading is used. And it shows the last stock that did not have the error so it leaves me guessing which stock came after that caused the error.
In general, when you run Exploration the issues are processed in alphabetical order. Although this sequence is not guarenteed for the reasons mentioned here:
... tracing stocks that are being processed, should definitely narrow your searches. If you additionally use TRACE with ThreadID information, I guess that the problematic issue should follow one of the lastly processed issues for each ThreadID (if TRACE is used at the end of the code) or be among them if used at the beginning. So in case of 4 threads - it should narrow your searches to 4 stocks. And (as a test) you can also run the exploration in one thread to get precise information...
But as I wrote, I don't expect that this knowledge will be specially useful to get rid of your problem. If there is really a connection problem, it can happen any time ...
To verify the nature of the problem, you can also try retrieving some data from the plugin using GetRTData (available only in professional edition). It retrieves the most recent value reported by streaming real time data source. If the connection is broken, you won't be able to do that.
Lastly I used to have similar problems with automatic re-running Exploration (when I was using it to extract data from the Internet) and it was one of the reasons why (in some cases) I decided to use chart/indicator based solutions instead of analysis (which if stopped because of an Error, has to be run manually or via OLE). I wrote about it in this thread: