then all the data has to be called from the DB first and then calculated
I would avoid the author who gave you that advice. Access "attempts" to pass through every query. As others have mentioned, some things might prevent that so you do need to avoid some VBA and all UDF functions in your where clauses in particular. If you use VBA or UDF functions in your where clause, that will not prevent Access from sending the rest of the query to the server for processing. But if it can't send the where clause, Access will ask for all rows to be returned. If the WHERE clause can be sent then only the desired records are returned. Access can then apply your non-translatable VBA functions and your UDF's on the records that are returned.
If you don't use criteria in your query then ALL rows are returned from the table and this is what you want to avoid at all costs.
Keep in mind that Access is a RAD (Rapid Application Development) tool and it does things the "Access" way. If you don't want to do things the "Access" way, do NOT use Access. You will be very unhappy and will cause yourself an excessive amount of work. pass-through queries bound to forms make the forms NOT updateable. Nor are forms bound to stored procedures. SP's are frequently used as the recourdsource for reports or to do batch processing. They are rarely used in forms.
Views are very useful for making joins more efficient.
Applications that were originally built for Jet/ACE BE's can be difficult to convert since they rarely use good client/server techniques like binding forms to queries with criteria that severely limits the rows returned. Their forms rely on form filters. If you were to simply convert the tables in one of these apps and not change anything else, the app would most likely be slower than it was when bound to Jet/ACE which always surprises people.
What is your objective in converting the BE? All my apps are built with the ability to convert to SQL Server or another RDBMS whether the client intends to convert them or not. The point being, using good client/server techniques does not interfere with using Jet/ACE. But, using them from the beginning makes me able to convert an app from Jet/ACE to SQL Server in hours rather than days or weeks. I even have one app which is sold to the public that allows the purchaser to choose to install the SQL Server BE or use an ACE BE. There are a couple of places where I needed parallel code but the rest of the app is built for ODBC and Jet/ACE are just fine with it.