Computer tutorials, tips, and tricks to help you learn Microsoft Excel, Access, Word, and lots more. Visit our full site at www.ComputerLearningZone.com.
Time for a quick Access quiz. These five questions cover a handful of small but important details involving form properties, macros, control events, fonts, and section references. They are exactly the kinds of things that can trip you up when everything looks fine in the Property Sheet, but your macro suddenly decides to throw a tantrum.
Give yourself a few seconds for each question before reading the answer. No cheating. Well, very little cheating. If you get all five, congratulations: your Access skills are operating at peak desktop nirvana.
Question 1: When a macro changes a control's Height or Width property, what unit does Access use?
A. Screen pixels B. Twips C. Inches D. Points
Answer: B. Twips. Access uses twips for measurements such as a control's Height, Width, Top, and Left properties. There are 1,440 twips in one inch. The Property Sheet may display measurements in inches depending on your settings, but the actual property value used in expressions and macros is typically in twips. If you are not sure what number to use, check the current property value and work from there.
Question 2: You want a notes text box to expand while the user is editing it and return to normal afterward. Which event setup is most appropriate?
A. Expand it in On Click and shrink it in On Double Click B. Expand it in On Load and shrink it in On Close C. Expand it in On Got Focus and shrink it in On Lost Focus D. Expand it in Before Update and shrink it in After Update
Answer: C. Expand it in On Got Focus and shrink it in On Lost Focus. Got Focus fires when the user enters the control, whether they click in it or tab into it. Lost Focus fires when they move away. That makes these events perfect for a temporary zoom effect on a notes box or any other field where the user may need a little extra room to work.
Using Click is a common beginner mistake because it seems like it should work. But Click only catches mouse activity. A user who tabs into the control would miss it entirely. Got Focus handles both situations without making you build separate logic for each.
Question 3: Why is it usually best to use a common Windows or Office font when setting a control's Font Name in an Access application?
A. A missing custom font can produce unreliable or substituted results on another computer B. Access can assign Font Name only to labels, not text boxes C. Custom fonts can be used only in reports D. Font names must always be numeric values
Answer: A. Access can request just about any installed font, but that font has to exist on the computer running your database. If it does not, Windows may substitute another font, and suddenly your carefully aligned form looks like it was assembled during a power outage.
For databases that will be shared with other users, stick with common fonts such as Calibri, Arial, Tahoma, or Times New Roman. Tahoma remains one of my personal favorites. It is clean, readable, and unlikely to disappear when your database gets copied to someone else's machine.
Question 4: A macro uses SetValue to change a text box's BackStyle. Why can assigning the text "Normal" cause an error?
A. BackStyle can be changed only in VBA B. SetValue can modify only bound fields C. BackStyle must be assigned a color expression such as RGB() D. BackStyle uses a numeric property value rather than the displayed word
Answer: D. The Property Sheet often displays friendly labels, but not every property is actually stored as text. BackStyle is numeric: Normal is 1 and Transparent is 0. A macro using SetValue needs the underlying numeric value, not the word shown in the drop-down list.
This is one of those Access details worth remembering. The Property Sheet is designed for humans. Macro expressions have to work with the actual value Access expects. If a property setting looks like a word but refuses to cooperate in SetValue, check whether it is really an enumeration or numeric setting hiding behind a friendly label.
Question 5: In a macro, which reference targets the BackColor of the Detail section on an open form named CustomerF?
A. Forms!CustomerF.BackColor B. Forms!CustomerF!Detail.BackColor C. CustomerF!BackColor D. Forms!Detail!CustomerF.BackColor
Answer: B. Forms!CustomerF!Detail.BackColor. You start with the Forms collection, identify the open form, then identify the Detail section, and finally specify the property you want to change. The visible background area of most forms is the Detail section, so that is usually the BackColor property you are looking for.
There are often multiple valid ways to refer to objects in Access, especially when you are working inside a form module or form-level macro. But when you need a fully qualified reference to an open form's Detail section, Forms!CustomerF!Detail.BackColor is the clear and reliable choice.
So, how did you do? If you missed a couple, do not worry. These are not huge concepts individually, but they are the little nuts and bolts that make Access forms and macros behave properly instead of acting like a Windows 95 machine trying to dial into the Internet.
These topics and plenty more are covered in Access Advanced Level 3, Lesson 2. Watch the embedded video for the quiz and explanations, then check out the course if you want to dig deeper into form properties, macros, events, and making your Access applications a lot more polished.
Think you know your Access SQL? Here is a quick five-question quiz covering some of the basics that every serious Access developer should have down cold: SELECT, FROM, WHERE, ORDER BY, field order, and that little asterisk that seems harmless until it comes back to haunt you.
Give yourself a few seconds to answer each question before checking the answer. No peeking. This is the honor system, and Access knows when you lie. Probably.
Question 1: Which SQL clause is used to sort the records returned by a query?
A. WHERE B. ORDER BY C. FROM D. SELECT
Answer: B. ORDER BY
The ORDER BY clause controls the order in which records appear in your query results. For example, you might sort customers by LastName, invoices by InvoiceDate, or products by Price. It does not change the records in the table. It only changes how Access displays the results.
Question 2: What does the asterisk mean in this SQL statement: SELECT * FROM CustomerT;
A. Return all fields from CustomerT B. Return only records with an ID value C. Sort the records alphabetically D. Return only calculated fields
Answer: A. Return all fields from CustomerT
The asterisk is essentially SQL shorthand for "give me all available fields." So SELECT * FROM CustomerT returns every column from CustomerT.
This can be convenient while you are experimenting or quickly looking at table data. However, in real-world queries, I generally prefer listing the fields I actually need. It makes the query easier to read, avoids returning unnecessary data, and prevents surprises if somebody later adds a new field to the table.
Question 3: What is the purpose of a WHERE clause in a SELECT query?
A. It changes the names of fields in the table B. It determines the order of returned columns C. It limits the records returned to those meeting a condition D. It permanently deletes records that do not match
Answer: C. It limits the records returned to those meeting a condition
The WHERE clause is where you put your criteria. If you only want customers in New York, unpaid invoices, active employees, or orders placed this month, WHERE is what narrows down the records.
A SELECT query with a WHERE clause does not delete anything. It simply shows you the records that meet your condition. SQL can certainly delete records, but that requires a DELETE query, which is a whole different animal and one you should approach with appropriate respect and possibly a backup.
Question 4: In a SQL Row Source for a combo box, what determines the order of the columns returned by the query?
A. The order of fields in the source table design B. The field used in the ORDER BY clause C. The order in which fields appear after SELECT D. The combo box's Tab Order property
Answer: C. The order in which fields appear after SELECT
This one catches a lot of people. ORDER BY controls the order of the records, vertically down the list. The fields after SELECT control the order of the columns, horizontally across the query.
That matters a lot with combo boxes. If your Row Source begins with CustomerID and then FullName, the first returned column is CustomerID and the second is FullName. Your Bound Column and Column Width settings depend on that sequence. Rearrange the SELECT list, and you may suddenly bind the wrong value without realizing it. Fun times.
Question 5: Assume every field comes from CustomerQ and none of the field names contain spaces. Which edit can shorten this SQL without changing its results?
SELECT [CustomerQ].[CustomerID], [CustomerQ].[FullName] FROM CustomerQ;
A. Remove CustomerID from the SELECT list B. Remove the FROM CustomerQ clause C. Replace SELECT with ORDER BY D. Remove the CustomerQ prefixes and square brackets
Answer: D. Remove the CustomerQ prefixes and square brackets
If every field in the query comes from the same source, Access can usually identify the fields without repeating the table or query name in front of each one. And if the field names are simple names without spaces or special characters, brackets are optional too.
So the shorter version can simply be: SELECT CustomerID, FullName FROM CustomerQ;
There are times when table prefixes and brackets are important. Prefixes are especially useful when joining tables that have similarly named fields, and brackets are necessary when names contain spaces or reserved words. But when they are not needed, removing the clutter makes your SQL much easier to read.
If you got all five right, congratulations, you have successfully navigated the SQL energy cloud. If not, no worries. These are exactly the kinds of little SQL details that become second nature once you start building more queries, forms, combo boxes, and reports in Access.
Watch the embedded video if you want to take the quiz along with the timer. These SQL topics and plenty more are covered in Access Expert Level 3, Lesson 1.
Cascading combo boxes have always been one of those little Access tasks that sounds simple until you have to build it. Pick a country, filter the state list. Pick a state, filter the city list. Pick a category, filter the products. Traditionally, that meant writing an After Update event, running a Requery, and making sure every piece of the plumbing stayed connected. It worked, but now Access 365 has a built-in way to handle ordinary cascading combo boxes and list boxes without VBA.
The big news is that Access can now link dependent combo boxes using properties that should look familiar if you have ever worked with subforms: Link Master Fields and Link Child Fields. This is not just a nice convenience for beginners, either. The really important improvement is that these linked controls work properly in Continuous Forms, Datasheet View, and Split Forms, where the old shared-row-source approach could get pretty spicy.
A cascading control is simply a list whose available choices depend on another control. The first control is the parent, sometimes called the master. The next control is the child. The parent supplies a value, and the child list displays only records that match that value.
For example, suppose a customer form has Country, State/Province, and City fields. Once the user selects United States, the State combo box should show Florida, New York, Texas, and so on. It should not offer Ontario or British Columbia. Once the user picks Florida, the City combo should offer Cape Coral, Miami, Fort Myers, and other Florida cities, but not Toronto or Vancouver.
That is not just about making the form look fancy. It helps prevent invalid combinations, keeps giant dropdown lists short, and makes data entry much easier. Nobody wants to scroll through every city in the database just to find one in their selected state. Well, maybe somebody does, but I would not hire that person to design my forms.
The new feature uses two properties on the dependent combo box or list box. Link Master Fields identifies the value coming from the parent control. Link Child Fields identifies the field in the child control's Row Source that must match it.
Using the Country to State example, imagine that your Country combo box is named CountryCombo and stores a numeric CountryID. Your State combo box gets its choices from a State table or query containing StateID, StateName, and CountryID. On the State combo, you set Link Master Fields to CountryCombo and Link Child Fields to CountryID. Access then handles the filtering automatically.
The important part is that the child combo's Row Source must include the matching field. In this case, the State combo must include CountryID in its Row Source. It does not have to be visible to the user. You can hide that column, just as you normally hide key fields in a relational combo box, but Access still needs the field available behind the scenes.
Also, the dependent control must use a Table/Query Row Source Type. This does not work with a Value List. A Value List is just a fixed collection of typed-in values, and Access has no relational field available to use for the link. If you want a proper cascade, use a table or query as the source for the child combo or list box.
The setup can continue through as many levels as you need. For a City combo box, include CityID, CityName, and StateID in the Row Source. Then set its Link Child Fields property to StateID and its Link Master Fields property to your State combo box. Country filters State, State filters City, and you have a three-level cascade without writing routine VBA event code.
One thing I strongly recommend is giving your controls useful names. Call them CountryCombo, StateCombo, and CityCombo. Do not leave them as Combo39, Combo42, and Combo57 unless you enjoy making your own life difficult. When you open the Link Master Fields dropdown and see a list of control names, CountryCombo tells you exactly what it is. Combo39 tells you that somebody made a combo box at some point in history. Possibly during the Clinton administration.
The real technical win here is how this works in a Continuous Form. In a normal single-record form, the new feature mainly saves time and eliminates a little code. With a Continuous Form, however, several records can appear on screen at once. Access is still using one control definition behind the scenes for all those visible rows, which is why traditional cascading combo techniques could be troublesome.
With the older method, you would often requery the child combo for the current record. That could leave another visible record looking blank if its saved child value was not included in the currently filtered Row Source. The data was still there. Access just could not display it because the combo's list was currently filtered for a different record.
The new built-in linking is record-aware. Access can evaluate the relationship separately for each displayed record. A Continuous Form can show one customer in the United States with Florida selected, another customer in Canada with Ontario selected, and another customer elsewhere with the appropriate matching value. This is also particularly useful for people who do a lot of work in Datasheet View or Split Forms.
The older VBA method is not obsolete, by the way. It is still useful to understand After Update events, Requery, Row Sources, query criteria, and the ways VBA can dynamically build a list. Those are important Access Legos that apply to plenty of other situations. Microsoft has simply given us a power drill for a job where we used to reach for a screwdriver.
If your new cascade does not work, check the basics before blaming Access. Make sure the parent is providing the same kind of value the child field expects. If CountryCombo stores a numeric CountryID, the CountryID in the State combo's Row Source should also be numeric. Make sure the child linking field is actually included in the Row Source, even if it is hidden. And make sure the child control's Row Source Type is Table/Query.
Another common issue is changing a parent value after a child value has already been selected. If a customer had Florida selected and you change their country to Canada, Florida is no longer a valid state choice. Access will require a new valid dependent selection. That is exactly what you want. It prevents bad combinations from being saved, such as Canada and Texas or United States and Ontario.
This feature was announced on September 24, 2026, and is rolling out gradually to Microsoft 365 Access users on the Current Channel, Version 2609. Gradual rollout means two people can both show the same version number, while one has the new properties and the other does not yet. If you do not see Link Master Fields and Link Child Fields on your combo or list box property sheet, check for Office updates, but do not panic or reinstall Office seventeen times. It may simply not have reached your installation yet.
These properties are a very welcome addition to Access. They reduce routine form plumbing, make dependent lists easier to build, and finally make this kind of relationship behave properly across multiple visible records. The old techniques are still worth knowing, but for a straightforward country-to-state, category-to-product, or similar cascade, the new built-in approach is cleaner, easier, and much less likely to make you mutter at your monitor.
Watch the embedded video for the complete walkthrough, including building a Country, State, and City example from scratch and seeing the same linked combos work in a Continuous Form.
Microsoft Access Error 3163 is one of those messages that sounds simple until it shows up in a process that has worked perfectly for years. Access tells you, "The field is too small to accept the amount of data you attempted to add," but it usually does not have the courtesy to point an arrow at the field causing the trouble. Fortunately, this error is almost always traceable once you know where to look.
The key word in the error message is destination. The incoming data may be perfectly valid, but the field receiving it cannot hold that particular value. This commonly happens in append queries, imports, update queries, VBA recordsets, copy operations, linked tables, and automated backup routines.
The most common cause is a Short Text field that is not long enough. If a destination field has a Field Size of 50, it can store no more than 50 characters. Try to put 51 characters into it, and Access throws Error 3163.
Open the destination table in Design View and check the field's Data Type and Field Size properties. If it is a Short Text field and the smaller size is not an intentional business rule, increasing it may solve the problem immediately. Short Text fields can hold up to 255 characters. If the field legitimately needs to contain more than that, it may need to be a Long Text field instead.
Do not blindly change every field in your database to a larger size, of course. Some limits are real rules. A U.S. state abbreviation should be two characters. A product code may have a documented format. An outside system may impose a maximum length. Those are valid reasons for smaller fields.
But there is a big difference between saying, "This value must be two characters because the specification says so," and saying, "I made this 50 characters years ago because I figured nobody would ever need more than that." Future You has a habit of finding those old guesses at the least convenient possible moment.
One common misconception is that a Short Text field set to 255 wastes space by reserving 255 characters for every record. It does not. Access Short Text fields use variable-length storage. If a field allows 255 characters but stores the value "Rick," Access stores the actual value, not 251 invisible blank spaces just because the field could hold more.
This matters because, for ordinary fields such as first name, last name, company name, address, city, subject, and description, Short Text 255 is often a sensible modern default. It gives you breathing room without meaning every record becomes enormous.
I ran into this exact issue in one of my own backup processes. A website field used for subjects and descriptions had originally been limited to 50 characters. The old web form also enforced that 50-character limit, so for years everything worked nicely. Nobody could submit a longer subject, which meant the Access backup table never saw one either.
Later, the live website database moved to SQL Server, where the corresponding field was defined as NVARCHAR(255). The Access backup table remained at Short Text 50. That mismatch sat quietly in the background for years because the old web form continued to enforce the smaller limit.
Then a new automated data-entry path came along. The newer process wrote a perfectly valid subject directly to SQL Server, bypassing the old web form and its 50-character rule. SQL Server accepted the value without complaint. The backup routine then tried to copy that same value into the old Access field limited to 50 characters. Boom. Error 3163.
The backup routine had not suddenly gone bad. The new process simply exposed an old mismatch between two systems that were supposed to store the same logical piece of information. That is a classic example of schema drift: structures gradually stop matching even though the data is expected to flow between them.
The repair in that case was easy. The Access backup field was changed from Short Text 50 to Short Text 255 so it matched what the SQL Server source was allowed to send. The important lesson is that backup tables, archive tables, import tables, staging tables, linked databases, and cloud-connected systems all need compatible definitions.
Error 3163 is not always about text, however. The message says the field is too small, not necessarily that the text is too long. Number fields have limits too. For example, an Access Number field with a Field Size of Integer can only hold values from -32,768 through 32,767. If you attempt to store 44,561 in that field, it will not fit. You may need to use Long Integer instead.
This is why it is important to inspect the actual value being written, not just the field name you think is involved. Compare the source field and destination field side by side. Check their data types, text lengths, numeric sizes, and whether one side is allowing values the other side cannot accept.
Incorrect field mapping is another common cause. This often happens with SQL INSERT statements, append queries, imports, or VBA code that assumes fields will always be in a particular order. A long description might accidentally get sent to a short code field. A text value could wind up headed for a numeric ID field. The data itself may be fine, but it is being delivered to the wrong mailbox.
When writing INSERT statements, explicitly naming the destination fields is much safer than relying on the physical order of fields in a table. Likewise, with an append query, open it in Design View and inspect the Append To row. Make sure each source field is really being sent to the destination field you intended.
Lookup fields and combo boxes can make troubleshooting even more confusing. You might see "Acme Corporation" displayed on a form, but the underlying field may actually store CustomerID 42. The friendly text is for humans. The stored numeric value is what Access is actually saving.
If Error 3163 occurs around a combo box or lookup field, check the underlying table field type and the combo box's Bound Column. Make sure your query, macro, or VBA code is writing the stored ID value, not trying to write the displayed company name into a numeric foreign key field. What you see on screen is not always what is stored under the hood.
If everything appears correct, go back through the basics before assuming database corruption. Verify the source value. Verify the destination Data Type and Field Size. Verify your mappings. Compare linked, backup, archive, and source table definitions. Check whether a newer import, automation, API, or data-entry process is bypassing validation that used to protect the database.
After you have checked the design issues, Compact and Repair is a reasonable next troubleshooting step. It can resolve some strange behavior caused by damaged definitions or database issues. If one particular field continues behaving suspiciously, creating a fresh field with the correct definition, moving the data into it, and replacing the old field can sometimes clear up the mystery.
Do not jump straight to registry cleaners, malware fixers, or generic "repair your PC now" websites. Error 3163 is usually a database design, schema compatibility, or field mapping problem. Start with the actual table design and the actual data being written. Access is usually trying to protect you from storing data incorrectly, even if it could be a little more helpful about telling you where the problem is.
The bottom line is simple: find the destination field, determine what value Access is trying to put there, and make sure the field's type and capacity can handle it. For text fields, check Field Size. For numbers, check numeric range. For appends and imports, check mappings. For systems that exchange data, make sure their schemas agree.
Also make sure automated jobs and backup routines have proper error handling. A visible failure is annoying, but silent data loss is much worse. Error 3163 may interrupt your day, but at least it stops the process before Access quietly chops off information and pretends everything is fine.
For a full walkthrough with examples of Short Text sizes, numeric field limits, append mappings, lookup fields, and the real-world backup problem that triggered this lesson, watch the embedded video above.
The person who built the Microsoft Access database your business depends on has left the company. The database still works, but nobody wants to touch it because nobody knows what might break. That is a stressful situation, especially when the database handles customers, orders, invoices, scheduling, inventory, or some other part of the business that absolutely cannot just stop working on a Tuesday morning.
The good news is that a working Access database is not automatically a disaster just because its developer is gone. You do not need to immediately throw it away, move everything to the cloud, hire a full-time IT department, or become a VBA programmer yourself. You need to protect what works, find out what you actually have, and make a sensible plan before something forces you to make a rushed decision.
First, figure out whether you have an emergency or a planning problem. If people cannot enter orders, print invoices, run payroll, or access critical information today, then deal with that specific failure first. This is not the time to launch a grand modernization project while somebody is waiting on month-end reports.
But if the database is still doing its job and the concern is simply that nobody knows how to maintain it, then you have something valuable: time. A working system gives you breathing room to investigate carefully, preserve what is important, and decide how to support it going forward.
Before anyone changes anything, find the actual pieces of the system. In many Access applications, the file employees open contains the forms, reports, queries, buttons, and VBA programming. That is commonly called the front end. The actual business data may be somewhere else entirely, often in a separate Access database file on a shared network folder. It might also be in SQL Server, SharePoint, Excel files, or some other data source.
Do not assume that the shortcut on somebody's desktop is the whole system. That shortcut is usually just the front door. You need to know where it leads.
Find the application files, the data files, and the backups. Identify which employees or company accounts can access them. If the database uses a shared drive, make sure it is really a company-controlled shared drive and not a folder on the former employee's workstation that everyone quietly depended on for years.
You should also find out whether an editable development copy exists. Access developers often distribute an ACCDE file to users. An ACCDE is a compiled version of an Access application that users can run but cannot easily modify. The editable development version is normally an ACCDB file. If the ACCDB file is available, protect it. If it is missing, look through backups and company storage first. If appropriate, contact the former developer and ask whether they have a copy.
A missing editable source file does not necessarily mean the system must be rebuilt, but it does mean you should get an experienced Access developer to assess the situation before anyone makes big promises. There is a big difference between "this is inconvenient to maintain" and "this is impossible to maintain."
Next, look for the things around the database that may not be obvious. Access applications often depend on more than just tables, forms, and reports. They can rely on linked spreadsheets, network folders, imported text files, scheduled tasks, printers, email accounts, Outlook settings, external databases, and services configured under a particular employee's login.
Maybe somebody downloads a spreadsheet every month and saves it in a particular folder so Access can import it. Maybe a button emails invoices through an account nobody else knows the password for. Maybe a report pulls information from a file on an old computer under someone's desk, next to three years of coffee cups and a printer that has not worked since 2019.
Those are all dependencies. They are the supporting pieces your database expects to find. You do not have to understand every technical detail immediately, but you should make a simple list of what people know. Document important folders, recurring imports and exports, automated emails, special reports, outside services, and anything that happens on a schedule.
This is how you avoid discovering six months later that the month-end process stopped because an account was disabled when the former employee left.
Now let us talk about backups, because this is where a lot of businesses get a false sense of security. You want backups of both the application and the data. If your database is split, backing up only the front end is not enough. Backing up only the back end is not enough either. You need both.
More importantly, test the restore process. A backup that has never been restored is like a spare tire you have never checked. It may be there. It may also be flat, missing, or belong to a lawn mower.
Restore a copy somewhere safe and make sure it opens. Make sure the data is present. Make sure users can perform the basic tasks they need to perform. Record where the backups are stored, who can access them, and what date they represent. Keep an off-site copy too, whether that means cloud storage, another location, or a properly managed backup service.
Also, do not let someone experiment directly on the live database. The live system is called production, because that is where the real work happens. Production is not where we conduct science experiments. Preserve a known-good copy first, then let any investigation, repair, or development happen in a separate test copy.
Your employees also know more about the system than they may realize. They might not know VBA, table normalization, or the difference between an inner join and a left join, but they know how the business uses the database every day. That knowledge is incredibly valuable.
Have key employees demonstrate their normal work. Record or document how an order is entered, how an invoice is printed, how a customer return is handled, how a special price is applied, and what management expects from end-of-month reports. Pay special attention to exceptions, workarounds, and those little steps that everyone knows but nobody has ever written down.
A strange-looking button on a form may appear unimportant to a new developer. Then someone explains, "Oh, that is how we handle our largest customer's special shipping arrangement." Suddenly that odd button is not so odd anymore.
This is business documentation, and it is different from technical documentation. Business documentation explains what people do and why. Technical documentation explains how tables, queries, forms, reports, and code work together. Eventually, a future developer needs both. But do not wait for perfect documentation before getting help. Perfect documentation is a mythical creature, right up there with the empty inbox.
If possible, look inside your company for someone who is interested in becoming the internal point person. This does not mean the business owner has to become an Access programmer. Running the business is already enough work. But perhaps you have an office manager, bookkeeper, operations person, or power Excel user who enjoys figuring things out.
Someone who already understands the business has a major advantage. They know what a correct invoice looks like. They know which report causes panic on the last business day of the month. They know what the staff means when they say, "It is doing that thing again."
An interested employee can start by learning the Access basics: tables, queries, forms, reports, and some basic troubleshooting. They may eventually be able to handle simple tasks, answer routine questions, and communicate more effectively with an outside developer. Do not expect them to instantly inherit a complicated application full of old VBA code and undocumented business rules. That would be like handing someone a wrench and declaring them an automotive engineer.
For many small businesses, the best long-term arrangement is a combination of internal and outside help. The internal person understands the business and can coordinate requests. The outside Access developer handles repairs, complicated programming, database design, and larger changes.
If you need outside help, look for someone with experience taking over existing Access applications. That is a different skill from building a shiny new database from scratch. A good developer should begin by understanding what exists, preserving what works, identifying risks, and helping you make informed decisions.
Ask practical questions before there is an emergency. How do they communicate? What information will they need? What is their availability for urgent issues? How do they handle support requests? Can they provide same-day help during business hours if that matters to your business?
Do not assume that a consultant is automatically available at 9:00 on Monday morning because something broke over the weekend. If your business needs rapid response, discuss that expectation before the day you need it.
It is also reasonable for an experienced developer to charge for an assessment. An unfamiliar Access application may contain years of forms, reports, queries, VBA code, linked tables, hidden dependencies, and business rules that were never documented. What appears to be a simple request on the surface can have consequences throughout the system.
However, make that assessment a defined purchase. Ask what the developer will examine, how the fee is determined, what spending limit applies, and what you will receive when the assessment is finished. You should come away with useful information: a basic system overview, known dependencies, immediate risks, missing files or credentials, and recommended next steps.
Even if you decide not to continue with that particular developer, you should be in a better position than when you started. If the proposal is vague, ask questions. If the price seems unreasonable, get another opinion. Compare the work being proposed, not just the largest number at the bottom of the estimate.
One thing to watch out for is turning a maintenance concern into an unnecessary replacement project. You may hear that Access is old, everything needs to move to the cloud, or you need to throw away the current system and build a modern web application. Maybe you do. But "maybe" is not a business case.
Ask what actual problem a replacement is supposed to solve. Is Access failing to meet a real business requirement? Is the current design fundamentally broken? Are there security, performance, remote-access, or support issues that cannot reasonably be addressed? Or does the consultant simply prefer a different platform?
The same standard works both ways. Keeping Access should be a deliberate decision based on whether it still serves your business well. But replacing it has costs far beyond making prettier screens. Someone has to understand the old business rules, migrate the data, test the new system, train employees, and recreate all those important little workflows that nobody remembered until they vanished.
A modern-looking web page is not automatically an equivalent business system.
Finally, use this experience to prevent the next knowledge gap. Assign someone internally to coordinate database information. Keep company-owned credentials, support contacts, backups, documentation, and source files under company control. Do not let essential access live only in one person's memory or personal account.
The goal is not to create one new keeper of all the database secrets. The goal is to make sure the knowledge belongs to the business. If the person who understands the system is unavailable tomorrow, somebody else should know where the files are, how the backups work, who provides support, and what the database is supposed to do.
If your Access developer has left but the database is still working, do not panic. Protect it. Document it. Back it up. Find the dependencies. Capture the business knowledge your staff already has. Then build a support plan that combines internal coordination with outside expertise when necessary.
That is usually a much smarter first move than tossing a working system into the dumpster just because the person who built it is no longer in the building. Watch the embedded video for the full discussion and a few more practical considerations.
Think you know your way around a basic Microsoft Access select query? This quick quiz covers five important query concepts that beginners need to get right, especially the part where you edit data in a query and accidentally discover that, yes, you were editing the real table data. No undo button from the moon base required, but it helps to know what is happening.
Give yourself a point for each correct answer. Try answering each question before reading the explanation. If you get all five, congratulations: you are ready to keep the Luna City database running smoothly. If not, no worries. That is why we practice.
Question 1: What is the purpose of a select query in Microsoft Access?
A. To display selected data from one or more tables B. To permanently copy records into a new table C. To print a formatted report D. To change every record in a table automatically
Answer: A. To display selected data from one or more tables.
A select query lets you choose the fields and records you want to see from one or more tables. You can filter records, sort them, combine related information, and display only the columns that matter for a particular task. It is not normally a separate copy of your data. It is more like a custom window into the data already stored in your tables.
Question 2: You need to filter customers by CreditLimit, but you do not want users to see the actual credit-limit amounts. What should you do?
A. Remove CreditLimit from the query after entering the criteria B. Include CreditLimit in the query, enter criteria, and clear its Show box C. Put CreditLimit only in the table's primary key D. Convert CreditLimit to a Short Text field
Answer: B. Include CreditLimit in the query, enter criteria, and clear its Show box.
This is one of the handy little tricks in the query design grid. A field does not have to appear in the results just because you need it for filtering. Add CreditLimit to the grid, enter your criteria in the Criteria row, and then uncheck the Show box for that field. Access will use the field to decide which records belong in the result, but users will not see that column.
For example, you could display customers whose credit limit is over a certain amount without putting everyone's credit limit right out there for the office gossip committee to review.
Question 3: In a query design grid, you sort LastName ascending and FirstName ascending. Which field must be farther left to sort by last name first?
A. FirstName, because Access reads sorts from right to left B. Either field, because Access sorts alphabetically by field name C. LastName, because query sort priority runs from left to right D. The field with the shorter values
Answer: C. LastName, because query sort priority runs from left to right.
In the Access query design grid, the leftmost sorted field has the highest priority. Put LastName to the left of FirstName, and Access will first arrange everybody by last name. Then, when several people share the same last name, it will sort those people by first name.
If you reverse the field order, you get a first-name sort with last name used only as the tie-breaker. That may not sound like a big deal until you are looking for Smith, John and Access has decided John comes before everybody else named anything.
Question 4: What normally happens if you edit an editable value while viewing a select query?
A. The change affects only the query's temporary results B. Access creates a new record in the source table C. The query becomes permanently read-only D. The change is saved to the underlying table record
Answer: D. The change is saved to the underlying table record.
This is the big one. A select query is usually a live view of the data in its source table or tables. If the query is editable and you change a value in Datasheet View, you are changing the actual underlying record.
The query result is not a harmless temporary spreadsheet. It is real data. If you change a customer's phone number, status, address, or credit limit in an editable query, that change is saved back to the table record. So be careful when editing query results, especially when you are working with customer, financial, inventory, or other important data.
Not every query is editable. Some queries become read-only because of joins, aggregate calculations, grouping, unions, or other design choices. But when Access lets you type into a query result, assume you are modifying live data unless you have a very good reason to believe otherwise.
Question 5: A query is already open when another user changes a record so that it should now match the query criteria. You do not see it yet. What should you do?
A. Rebuild the query in Design View B. Refresh the query results, or close and reopen the query C. Save the query under a new name D. Add a new primary key to the source table
Answer: B. Refresh the query results, or close and reopen the query.
An open query does not always immediately redisplay changes made by someone else. If another user updates a record and it should now appear in your results, refresh the query with F5, use the Refresh command, or close and reopen the query.
This is particularly important in a multi-user database. The underlying data may have changed, but the rows currently displayed in your open query may not update until Access reloads them. Good old F5 can save you from thinking your query is broken when it is really just showing an older view of the data.
How did you do? If you got five out of five, you have earned at least an honorary lunar database badge. If you missed a couple, that is perfectly normal. Queries are one of the most useful parts of Access, and understanding how filtering, sorting, live edits, and refreshing work will save you plenty of headaches later.
Watch the embedded video for the quiz format and explanations, and if you want a more complete beginner-level lesson on customer queries, filtering, sorting, and working with query results, check out Microsoft Access Beginner Level 1, Lesson 9.
Twenty years is a pretty big milestone, especially on the internet, where many websites, forums, and software products seem to disappear before you can finish installing their updates. Computer Learning Zone has now been on YouTube for two decades, and that is something worth taking a moment to celebrate.
The channel began in September 2006, when YouTube itself was still a fairly new idea. At the time, nobody was talking about creators with millions of views, giant subscriber counts, or people learning database design from videos on demand. The goal was much simpler: help people understand computers and technology, one lesson at a time.
Over the past 20 years, Computer Learning Zone has published 2,547 regular videos, not counting Shorts. Along the way, the channel has grown to more than a quarter-million subscribers and has received over 51 million views.
Those numbers are impressive, of course, but the one that really puts things in perspective is the total watch time. Collectively, viewers have spent more than 3.3 million hours watching Computer Learning Zone videos.
That is an absurd amount of time. If all of those hours could somehow be assigned to one person, that person would need roughly 376 years to watch everything continuously, 24 hours a day. Blaise Pascal could have started watching around 1650 and would just now be wrapping up. Of course, that would require time travel, a computer, YouTube, broadband internet, and probably a Star Trek episode to explain it all.
Would Pascal have enjoyed the lessons? I would wager he might have. Sorry, that one was unavoidable.
But seriously, every view represents someone taking time out of their day to learn something. Maybe it was a beginner trying to make sense of Microsoft Access. Maybe it was someone building an Excel spreadsheet for work, figuring out a Word document, learning VBA, working with SQL Server, or trying to solve some strange Windows problem that appeared out of nowhere after an update.
That is why the channel exists. Technology can be frustrating, especially when the people explaining it assume you already know everything. The goal has always been to break things down into understandable pieces, explain not only what to do but why it works, and occasionally make a bad joke while doing it.
A special thank-you goes to everyone who has watched a lesson, subscribed, left a comment, asked a question, shared a video, or simply stopped by to learn something new. And an especially big thank-you goes to the channel members and supporters who help make it possible to keep producing new lessons every day.
Teaching computers and technology has been a passion since 1994, long before YouTube existed and back when a computer manual was often thicker than the computer itself. After all these years, there is still something genuinely enjoyable about learning a new feature, solving a tricky problem, and then figuring out the clearest way to explain it to someone else.
And no, this is not the retirement announcement. There is plenty more on the way: Microsoft Access, Excel, VBA, SQL Server, Windows, Word, AI, and whatever other useful technology shows up next. Believe it or not, one of the channel's most popular videos is still about Microsoft Word. Go figure.
Whether you have been here since the early days or subscribed yesterday, thank you for being part of this little corner of the internet. Watch the embedded video for the full milestone celebration, and here is to the next 20 years. If viewers add another three million watch hours, Pascal may need to start over.
