What Are the Standard Steps when Designing a Server-Based Access Database?

I understand that this is a broad question, and I am trying to avoid asking a question that has intinite answers, but, there has to be a standard set of standard rules when designing an Access database for a server which I am missing.

The Reason I am asking is because I currently have a database, which started as a desktop app, and I now want to move it onto a server. However, I basically created this database on-the-fly, and currenty in debate of scrapping the front-end of the database because I feel like I am missing crucial steps on the development end. I really need an expert's opinion on the basic How-To's on structuring a server-based database.

Thank you for your time and consideration.

EDIT Here is a link to a great guideline which lays out the 'best practices' when making a server-based Access database.

http://www.opengatesw.net/ms-access-tutorials/Access-Articles/MSAccess-Deployment-Best-Practices.htm

Hope others find this as useful as I have.

There not any real changes in good designs you have in an existing Access application as opposed to using Access + SQL server.

In other words you can take your existing application and move the data tables to SQL server, and CONTINUE to use your existing Access application as a front end.

There no real advice here that applies to "only" Access without SQL server and that of using Access + SQL server. In other words, you don't really have to change how you build your Access application to work with SQL server.

Good designs that scale and work well in an Access only applications ALSO tend to work rather well when using Access as the front end and SQL server for the back end.

The basic tips are:

When you open a form, ASK the user BEFORE you launch the form. It makes no sense to launch a form that drags large numbers of records from the server and THEN ask the user what account# or whatever is required. So prompt the user for some type of search. Say a screen like this:

The above even when hitting SQL server with a million rows is INSTANT. And above uses 100% linked tables from Access without any special tricks here - just a simple SQL statement gets shoved into the sub form. So this is a linked view to SQL server.

Then when the user clicks on a row, you simply launch the form with a where clause ("ID = " & me!id).

This "where" clause works fine even with Access bound forms and linked tables too SQL server.

Use Views for complex queries in reports (that have client side filter requests).

And you can adopt pass-though queries for some reports for even greater performance, but in most cases creating views SQL side and linking to them from Access works well and is the least amount of work.

So there no real "changes" in how you develop your software with Access and SQL Server. The only issue is ALWAYS keep in mind that you do not want to load records into a form until such time you determined what the user wants to edit. This approach not only applies when using Access + SQL server, but even with just file based Access applications you don't need nor want to pull records unnecessary into a form to reduce network load.

A "simple" where clause attached to the OpenForm command will suffice in the vast majority of cases.

So there no "real" change in how you develop a good Access only application, or a Access + SQL server applcation.