Then open it as you would an Access query. If the date comes from a parameter or similar - use VBA to contract the SQL and set the pass through query SQL to be whatever you want then open it. They're not much different to Access queries (can only use then for select statements (and not crosstabs)), but must use SQL Server syntax - which is similar but not the same as Access - not that dates are encased in single quotes - as it text.

I'd try adding an index to the date field if not there. This will make the filtering a lot quicker. Select all doesn't need to do anything but bring it all back. While it appears quick, what you see is the first screen - the rest of the data is still loading many seconds later. The moment you sort or filter - a whole lot of work has to happen before you see the first records which is what makes it appear slower.

Further to last post, I suspect you are using a normal Access select query. Try doing this as a "pass through" query - you need to write the SQL in SQL Server syntax. This then makes the SQL server do the filter rather than Access and is usually much faster.

To create a pass-through query, you need to convert your Access SQL string to T-SQL. You then create a new query and paste in the SQL string. The QBE cannot display pass-through queries because a pass-through query is ALWAYS coded in the syntax of the target server. So, if the query is to run on an Oracle server, you use Oracle syntax. DB2 server, DB2 syntax, SQL Server, T-SQL, etc.

This is not usually necessary though since Access makes every effort to pass through ALL queries (you can defeat this if you don't understand the process though). Although there is certainly some overhead associated with the ODBC driver getting involved to convert the "Access" query before sending it off to the server, Access DOES send all queries off to the server for processing and the server returns only the records requested. So, regardless of whether the query is a pass-through or Jet/ACE, the heavy lifting still gets done on the server. The pass-through just saves some pre-processing. The thing you lose with pass-through queries is that they are not updateable and in my mind that is a huge loss.

The only time I have ever actually had to use a pass through query is for bulk updates. Access wraps each update in a transaction in order to allow you the ability to cancel. That takes a huge amount of workspace and extra time. With a pass-through query, you don't get the option to change your mind about applying the updates, once the query is sent, the action happens.

I have found that adding appropriate indexes and occasionally creating views that perform common joins provide sufficient responsiveness.