@wquery?

[paues]

Do you know which database formats that support the wquery command in Eviews 7.2 Enterprise Edition (given that the command is yet undocumented)?

[paues]

Perhaps this post has been forgotten? What I am after is what third-party database formats supports the @wquery command. I know that Macrobond does. But what about e.g. Datastream, Haver or Moody's?

[paues]

Also, will there be any documentation of @wquery before long? Or will that have to wait until EViews 8?

[EViews Chris]

Sorry about the delay ib responding.

The situation is actually pretty complicated.

The basic idea is that EViews always attempts to 'fill-in' any missing functionality in an external database format, but there are cases where this is not possible.

For all *disk based* local file formats (eg. Haver and Moody's Economy.Com) all search functionality is supported because EViews can simply read the metadata for every object in the local file and perform the search itself. (In practice, name pattern searches are often handled directly by the external code and all other fields are handled by EViews). The only difference from using an EViews native format database is that this may be consierably slower for some searches because EViews builds word by word indices on the description field which makes lookups on the description field very fast. Most other databases only index by name (or not at all).

With (remote) server based databases things get more complicated. The issue is that over a slow network connection, the strategy of fetching metadata on every object and then having EViews do all the filtering locally generally isn't feasible. Most server based databases will simply error if they receive a request for 'all objects' in the database. (The main IHS databases have millions of series in them so returning all objects is basically infeasible). So EViews will try the same strategy with server based databases but often you're going to come up against errors where the server refuses to return the requested object metadata because too many objects matched the (name pattern) criteria.

Most (but not all) foreign server formats support name pattern searching, in which case your search will succeed if it contains a name pattern and the name pattern matches sufficiently few objects. You can also provide additional search criteria to narrow things down by fields like frequency, start date, etc. which will be handled by EViews.

Datastream is in the category of server based databases where we don't really support any text expression searching at all. I'm not completely sure whether this is because the functionality isn't there at all or whether we haven't fully enabled it in this case. Complicated searches on foreign server based databases are generally fairly problematic, so we don't always chase up all the loose ends to enable everything that might conceivably be possible.

To summarize: foreign databases formats that store the data in local files (using a 'push' model to populate the local databases) typically have pretty good support for searching, server based databases (using a 'pull model' to fetch the requested data on the fly) generally don't.