Best Practice SQL Server/Access connections - sql-server

Question

At the risk of starting an ODBC/OLEDB arguement, does anyone have any best practice suggestions for linking an Access Front End to a SQL Server Backend?
I have read the articles about .ADP vs .MDB and have also been through the DNS-less connections information and agree with the thinking.
My main question is around linking the data and performance. In the past I have found forms to be slow when connected directly to the SQL database, I have tested forms based on ODBC linked tables vs an OLEDB connection in the 'OnOpen' event and found the OLEDB approach to be quicker although not great. Therefore I have implemented routines where the data is copied locally when opening a form, modified, then written back to the database when complete but this has its own problems.
Does anyone have suggestions on the best practice approach for this kind of setup? Am I missing something that will improve my forms that are linked directly to the SQL Server?
Any comments or hints appreciated.

Answer 1

You must reduce network traffic to a minimum, especially acknowledgement exchanges. Do this by running SQL exclusively on the SQL server as much as possible, transmitting only complete rowsets back to the client. At all costs avoid joining data on the server to data in the Access DB. That should get you started.

Answer 2

The basic approach is to simply use linked tables.
You should not be seeing any real difference here when using ODBC. ODBC is the preferred approach and Microsoft has announced the end of oleDB support (and the .net community left oleDB and ADO about 10 years ago).
You can bind a form to these linked tables and achieve good performance. The simply trick is to reduce and limit records pulled. This limiting can be accomplished by using a SIMPLE where clause when you launch those bound forms.
So, if you launch a bound invoice form and supply the where clause on the standard open form command then ONLY the one record is pulled. And if course if you have a bound sub form then only the correct records will be pulled from the server also. So no advantage here by using oleDB or ADO will exist in 99% of your cases.
So as a general development approach you can in most cases you can use bound forms.
Where caution is required is that for some joins and anything with aggregate queries, then you want to use a linked table to a sql view. You can also consider using pass-through for reports, but pass-through tends to be more work, and a linked view means you can keep your existing VBA code that likely (hopefully) used a "where" clause to open those reports and again restrict records pulled down the network pipe.
And for dynamic pass-through to execute server side commands, I use this code:
Dim qdfPass As DAO.QueryDef
Set qdfPass = CurrentDb.QueryDefs("MyPass")
qdfPass.SQL = "exec sp_myProc " & "p1"
qdfPass.Execute
If you need the above to return records, then just go:
Dim qdfPass As DAO.QueryDef
Dim rstData As DAO.recordSet
Set qdfPass = CurrentDb.QueryDefs("MyPass")
qdfPass.SQL = "exec sp_myProc " & "p1"
set rstData = qdfPass.OpenRecordSet
So you can on the fly change/modify the above sql for a pass-through query with very little code. At the end of the day, you thus achieve first rate performance, and do so with very few coding changes to the existing application.
So the current recommend approach here is to use DAO. And do keep in mind that end of life support for oleDB (and ADO) for sql server has now been announced. See here:
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx