I think the point is that if your BE is Jet/ACE there is no gain by doing this conversion and if your BE is SQL Server, there is probably also no gain or at least not enough to justify the effort. If you have slowness, you need to better understand your schema and how to build queries and why to not use VBA loops or the build in form filters when you can use queries to do something.
I build all my apps with the intention of either immediately or at some later date being converted to using SQL Server. That mostly impacts how I define forms and filtering. It also affects queries since SQL Server cannot process VBA or UDF functions. They have to be processed in Access where VBA is available. So, although you can use VBA and UDF functions, you need to restrict them to the select clause so they can be applied AFTER SQL returns the recordset. If you need them in other clauses, you may need to later create stored procedures or pass through queries so mark the code and make notes to self. In the cases where I use DAO, it affects the code I use since SQL Server will in certain cases require dbSeeChanges (among other arguments). Well, I add the arguments NOW. Access doesn't care and I know that SQL Server WILL so my goal is to make the ultimate conversion as painless as possible and in most cases, I can convert an app I built to SQL Server in a day or so but the actual time really depends on how large the app is because it all needs to be carefully tested to make sure I haven't been sloppy and missed something.
So far, I've never had to convert to ADO. And, I've only rarely had to resort to stored procedures, unbound forms, views, and pass through queries. Most often, a view to take care of a join, solves a small slowness problem. But then so far, my SQL Server apps have been using sound LANs. If you are using remote databases, you may have to do a lot more work.
