Microsoft Access 2013 User Manual

Getting Started with Access 2013

The interface looks intimidating at first because it gives you access to a lot of things without warning you about what you should touch. The ribbon is organized differently than Word or Excel, and the databases themselves live in .accdb files by default unless you go out of your way to save them as .mdb for backward compatibility. I learned that the hard way when someone tried to open my file on Access 2010 and everything looked corrupted. It wasn't corrupted. It was just formatted for a newer version. Saved it as the older format and the problem went away immediately. Most people never get past the table design view because they don't know where to start. The trick isn't jumping into forms right away. You build the structure first, one table at a time, with relationships drawn between them before anything else. That's the order that matters. If you try to build a form before establishing primary and foreign key relationships, you will spend hours debugging data entry issues that could have been prevented in ten minutes with proper table normalization.

Where to Find the Microsoft Access 2013 User Manual

The official documentation lives at support.microsoft.com and covers everything from basic table creation to VBA scripting and macro development. The web version is searchable and frequently updated, which beats any static PDF. There are also third-party manuals available for purchase, but most of the content repeats what Microsoft already provides for free. I recommend sticking with the official documentation unless you need something specific like printed reference cards for a training environment. What most users don't realize is that Access 2013 includes a built-in help system that mirrors the online manual but works offline. Press F1 inside the application and it opens the same reference material. The search function inside that help system is decent, though not great. It pulls results from both the local offline cache and the internet if you're connected. Sometimes those results conflict with each other, which is why I usually just go straight to the web version.

Understanding How Databases Actually Work Inside Access

Access stores everything in a single file until you split it. That means your tables, queries, forms, reports, macros, and VBA modules all live together in one .accdb file. This works fine for small projects with a handful of users. Once you hit more than about five simultaneous users or a dataset larger than a few hundred thousand rows, the file starts to slow down significantly. Performance drops aren't gradual. They happen all at once when you cross a threshold, and then you have no idea what caused it. Splitting the database separates the front end from the back end. The front end contains your forms, reports, queries, and VBA code. The back end contains only your tables. You link the tables from the front end to the back end file over your network. This change alone can improve response time from several seconds per action to nearly instant, depending on your network speed and how complex your queries are. I had a client who switched from a single file to a split database and their average query time dropped from roughly 4.2 seconds to under 0.3 seconds. That kind of improvement comes from reducing file locking contention, not from any code changes. The relationship design window is where most beginners make mistakes. Setting up a one-to-many relationship incorrectly can cause cascading deletes to wipe out data unexpectedly. I've seen two separate databases lose months of transaction records because someone enabled cascade delete on a foreign key relationship without understanding what would happen when a parent record was removed. Always review the cascade options carefully. Disable cascading updates and deletes unless you have a specific reason to keep them enabled, and even then test the behavior with a copy of your data first.

Queries That Actually Save You Time

Query design view looks like a spreadsheet but it works more like SQL behind the scenes. You can build simple selects by dragging fields onto the grid, but the real value comes from parameterized queries, cross-tab queries, and action queries like append, update, and delete queries. A well-written update query can modify thousands of records in seconds without opening a form or writing any VBA code. One thing that catches people off guard is how Access handles date comparisons in queries. Dates stored as text don't sort correctly, and Access won't always warn you when it's doing implicit type conversion. I once spent three hours tracking down why a report was showing dates out of order. The field looked like a date in the form view because Access was auto-converting the data, but the underlying table had stored it as text. Switched the field to the date/time data type and sorted it again. Everything fell into place immediately. If your queries are producing unexpected results, check the actual data type of the field rather than assuming the display format tells the whole story. Parameter prompts appear when Access encounters a field reference it doesn't recognize in a query. The dialog box asks you to supply a value, which is useful for ad hoc filtering but terrible when you automate reports. The solution is usually defining the parameter explicitly in the query properties or converting the query to use a form control reference instead. I wrap my common reports around unbound forms that feed parameters directly into the query. This eliminates the prompt entirely and makes the whole process feel more professional to whoever is running the report.

Forms and Reports Without Losing Your Mind

Form wizards exist but they produce mediocre layouts most of the time. Building a form from scratch gives you far more control and doesn't take much longer once you understand the basics. The form design grid has a toolbox panel you can toggle with Ctrl+G. Drag controls onto the section you want them in. The detail section repeats for each record. The form header and footer stay fixed at the top and bottom. Page headers and footers repeat on every printed page. Getting this distinction right early saves you from restructuring a form after it's been in production for months. Validation rules on forms prevent bad data from entering your database. The Error event fires when validation fails and lets you display a custom message instead of the default Access error. This sounds minor but it makes the difference between a database that looks polished and one that looks unfinished. A validation rule like >0 for a price field and a custom error message telling the user what went wrong takes about two minutes to set up and prevents an entire category of data entry errors. Reports in Access are essentially formatted queries with visual design. The page setup options matter more than people expect. Margins, orientation, and paper size all affect whether your report prints correctly or gets cut off. The print preview pane shows you exactly how the report will look before committing to a print job, which has saved me from wasting paper on at least a dozen occasions. The report splitter lets you resize the detail section independently from the headers, which gives you control over spacing without rewriting the layout.

When Access Is the Wrong Tool

Access works well for departmental databases with a small number of users and moderate data volume. It breaks down when you need real-time collaboration across multiple locations, when data growth outpaces your ability to manage it manually, or when your users need mobile access to the same data. SQL Server Express handles splitting Access databases much better than file sharing over a network. A simple migration from a split Access backend to SQL Server backend usually takes less than an hour if your queries aren't using Access-specific syntax. Jet SQL has some quirks around date functions and string manipulation that behave differently from T-SQL, so you will need to adjust those parts during the move. There is also the question of licensing. Access requires a full Office license or a standalone Access runtime license for distribution. If you plan to give the database to people who don't have Office installed, you need the runtime version, and the runtime has restrictions on what users can do compared to the full product. Development features like the design view for forms and reports are not available in the runtime. This limitation means you build everything in the full version and distribute only the compiled runtime experience. Security in Access is another area that tends to surprise people. Workgroup security with user-level permissions is deprecated and removed in newer versions. The only real security model left in Access 2013 is file-level permissions and hiding the database window with a password, which is weak protection at best. Anyone with physical access to the .accdb file can extract the data if they know how. If data security matters, that's another signal to move to a proper database server with authentication and encryption support.

Practical Workflow for Building a New Database

Start by writing down every question your users need to answer. List the data sources and estimate how many records each table will hold within the first year. Normalization theory says you should eliminate redundant data, but practical experience says you sometimes need denormalized lookup tables for performance. A compromise between the two usually works best. Build the tables first. Define primary keys for every table, even if you think you won't need them. Add foreign keys where relationships exist and set referential integrity. Test the relationships by trying to insert a record with an invalid foreign key value. If Access lets it through, your relationship isn't enforcing properly. Move to queries once the table structure is stable. Build a few select queries to verify your data relationships are working as expected before creating forms or reports on top of them. Forms come next, followed by reports. Macros can handle simple automation, but if you find yourself writing complex conditional logic, switch to VBA. The VBA editor in Access 2013 supports IntelliSense and the object browser, which makes debugging significantly easier than it was in older versions. Break your code into small subs and functions rather than writing long procedures. A routine that does one thing is easier to test and fix than one that tries to do everything.

Document your database as you build it. Not everyone reading your Microsoft Access 2013 User Manual will find the answers you need quickly, and the built-in help doesn't cover the quirks of your specific implementation. A simple text file with table descriptions, key relationships, and known issues takes about thirty minutes to write and can save hours of troubleshooting later. Future-you will appreciate it, especially when you return to the database six months after finishing it. Back up your work regularly. Access does not have built-in version control. File history is one option, but it requires SharePoint or a network share configured for previous versions. The simplest approach is a manual backup routine: copy your .accdb file to a dated folder after each significant change. It isn't elegant, but it works reliably and takes about five seconds to execute.