Nothing in your post up to the point where the quote begins says anything about "lengthy results" - did something get dropped from your original post?

The other posters are correct that for simple queries, the ODBC driver takes the Access SQL statement and converts it to T-SQL and passes it on to SQL Server where it gets process, and results if any are returned to the user. But if more complex things are being done, the all of the data in all of the tables is passed back to the Access Jet engine where the query gets run, and that will always be slower. The real question is whether the difference is noticeable to the user. In many cases the answer is no - in some the performance hit can be truly awful.

The virtue of using Access as the front-end to a SQL Server database is that you can whip out forms, reports and queries faster than with any other existing technology, but if you are migrating an Access database to SQL Server, you do have to worry about performance. Simple queries with no more than three tables are often converted to T-SQL and you only get the results back. We've been doing this sort of thing for over 20 years, and have worked with databases containing multi-million row tables, and get sub-second response with the use of subforms and filters. The process we use is to simply upsize the back-end to SQL Server, and then do performance testing to see what needs attention. In those cases where performance is bad (or abysmal) we typically resort to pass-through queries, some of which are created on the fly, or to using views in SQL Server that do the joins we need, and occasionally to a stored procedure.

The bottom line is that it can be made to work and work well, but you have to pay attention to the design and the details.