Shay:
You may have different needs, so this may not work for your purposes. My backtest's have a desired starting date, and a required ending date, for the period of the backtest. I do not currently require all specified securities to have data on the start date, but require at least one. This is a "sloppy" algorithm, which is adequate for looking for strategies that may be attempted on a large list of securities (such as all members of the S&P500) -- All may not be present at the start date. However, I expect all to have data up to and including the "end date" of the specified time interval. The implication here, is if they are missing the last date, they probably have been de-listed, or have merged and are no longer trading candidates. So, by "current data", I mean the final date of the time interval must have historic data present. -- For volume, I merely note the zero cases in my log transcript, but do not typically act on it. -- Sometimes it may be wise to double check the data if volume is zero for highly liquid instruments. I use a number of the Quandl data sources and find them fairly reliable, but do find infrequent holes in their data. For these holes, since they are few, I dynamically correct the known ones, which has not been a big deal yet. (I maintain a Hash of date codes, where data may be duplicated, and should be pruned, for example -- so far these have been on weekends, which is clearly a bug in their data)
For Liquid products, I used a TOS scan, to provide my liquidity desires, and export that to a CSV, which I then use as input to my backtest tool to keep from having to write specific code to handle that.
I have not encountered the "resurrected symbol" issue yet. Wonder if you can deal with (prune) data based on requirement data is contiguous (no gaps in the data for your time interval of interest)?
