I'm not sure what you mean. So, you've defined some named queries in Omniscope using the filters or selection, and the Queries button next to the barometer? And you want to use these in DataManager?

Is this purely to save you the time of actually replicating the same queries in the Record Filter operation, or doesn't the Record Filter operation support all the querying options you want?

Would a Record Filter operation that referenced a saved XML query file (as previously exported from Omniscope's Queries menu) do what you want?

Hi Steve,

It is also a matter of time reg the Record Filter operation, but the way a named query is created (by filtering the various fields), is not possible in the Record Filter operation as you have to type manually the values per variable. This would be my main reason to have the named queries as part of the Record Filter operation after the Omniscope block.

The XML query file is something I haven't used before so I am not sure if that will do as well. It seems more complex and less user friendly than the way DM works. The visualization operations that DM makes possible is really great.

It isn't appropriate to have named queries used directly in DataManager. If this were the case, inadvertently adding records to a named query would mess up the data back-end.

Also, named queries in Omniscope are relevant to the data currently loaded into Omniscope. Whereas, in DataManager, you can have many different blocks with entirely different data structures (fields and data types).

So, I'm proposing allowing you to import (or reference) a named query export. To create this, you would need to Load the block being filtered into Omniscope, create your named query, export it, then import it (or reference it) in some kind of DataManager "Query Filter" block.

You could then perform further transformations on your data and load different data into Omniscope, and discard your named queries, without affecting your data model.

We will consider adding this in 2.7 if there is sufficient demand.