Design database tables properly
It is important to design your database tables properly, spending time and effort to make sure you get this right. If the underlying database structure is wrong everything you subsequently do is made much harder and may not even function at all. Table design issues to look out for include using the correct data types (don't use a numeric field for a telephone number for example), use indexing correctly and make sure your design is normalised.

Don't rely on the access wizards
The wizards are fine for producing a simple and quick database that meets one of the supplied examples but don't try and take them too far. If you want something that doesn't match one of the pre-defined templates you should look at the underlying structures to make sure that these will work with your proposed solutions. However, the Query Design wizard is great and very useful in making SQL more approachable. If you don't know what SQL is then you really need to undertake more advanced access training before tackling any significant database work.

Split your database
Split your database into at least two. Keep all your forms, reports and code in one 'code' database, and all your tables in another 'data' database which is linked to the 'code' one. This makes modifications, updates and backups much easier to perform and means you can work on new versions of your 'code' database without existing users being affected. It also makes it easier when you want to convert a single user database into a multi-user networked version.

Limit character use in field names
Don't use spaces, quotation marks or other punctuation characters in your field names. Stick to A to Z, a to z, 0 to 9 and underscore. The use of single or double quotation marks can mess up SQL causing your queries to fail. Spaces and other punctuation characters will work the majority of the time but require you to remember to put these field names in square brackets, and if you export data to another package you may find that it won't accept these field names. By avoiding them altogether you can save much heartache later.

Learn and use VBA
Learn and use VBA and you can completely forget about macros. Macros are fine but they can be very limiting. For example, you cannot include any error trapping within a macro and so if it has a problem your application will just crash without any warning. If you want to do any serious development using Access you really must use the proper programming language.

Limit your colour palette
Finally, don't be over enthusiastic with your colour palette. Using a limited number of colours from the more subtle end of the range is usually more effective and less distracting and irritating that a lot of glaring, bright colours.

The above illustrates a number of ways in which you can improve your database development. Many training companies offer instructor led Microsoft Access training courses where you can obtain these skills. Trainers have real development knowledge and are able to break down key concepts making them simple to understand. Those users new to Access will benefit from introduction access training, where they will learn how to use tables, field and records in combination with simple queries, forms and views. More advanced users tackling some of the more complex issues described above will benefit from advanced access training where they can develop skills in SQL queries and how they work in relational databases.

This article courtesy of: articles.net.au

The author is a trainer with a Microsoft Office Training company, the UK industry leader in its sector. For more information on Microsoft Access Training, please visit www.stl-training.co.uk/