Richard,

For each new instance of FNL a new ModuleId and a new TabModuleId is created. Each request queries only data for that instance from SQL server, it is filtered by ModuleId . DotNetNuke also offers also the ability to add existing instances. In that case the ModuleId remains but a new TabModuleId is used. FormAndList was designed to share the data in that case. It is a feature. TabModuleId (and the related TabSettings) allows to setup different views, forms and filters for each tab (page) against the same data. 

Filtering on TabModuleId would be counterproductive - as the decision to reuse and share the data was already made. If you don’t want to share data just add a new instance and get a new ModuleId. Use templates to build on top of existing schemas and XSL scripts.

I am aware that filtering on SQL filter is faster. The problem is that not all interesting data for filtering exists. It is not possible to filter for files (Download, Url Image datatype) or dynamic values (look up, calculated column…). Only types like string or numbers would benefit. It would now be simple for us developers adding an additional server-side filter setting. That filter expression would use a different syntax (T-SQL instead of DataSet expressions), would work against a limited set of datatypes and it might introduce new targets for SQL injections. In short,  it would make it much more difficult for the users of the module. FnL is already complicated enough.

Thanks

Stefan

1000 of linked version is the wrong approach, 1 instance per page would have been much better.
The search requirement could be solved with a custom module or a generic reports module (e.g.  Xml module with SQL Data Source).