Best practices for implementing an Microsoft Access application

Take a look at Tony Toews' Best Practices for Microsoft Access. Since you're developing a split application you owe it to yourself to also consider Tony's Auto FE Updater. That utility (which he offers for free) makes it fairly easy to roll out your application front end to the users, and make sure that they are always working from your latest app version.

I will also suggest you try to avoid basing your application's forms on large data sets. For example, rather than binding a form directly to a large table, bind it to a query which returns only one or a few rows from the table. Allow your users to select which row or rows they are interested in at any given time. The point here is to limit the amount of data Access must retrieve when the users open your form.

Here are a few links to get you started

http://www.mvps.org/access/

http://www.lebans.com/

http://www.blueclaw-db.com/

Right time to don my flame suit once more and fire up the bound –v- unbound debate once again. Personally I almost always use unbound forms for new work for the control and performance they offer.

The counter argument to that is by using unbound forms you are chucking away a lot of what makes access access however for me anyway I maintain that the greater control and performance outweighs that and once you get into the swing of it I would say the development time is only very slightly longer.

Interesting topics around Access 2007:http://allenbrowne.com/Access2007.html