Quick Queries #104
By Richard Rost
8 hours ago
Why I Think Calculated Table Fields Are Evil In today's Quick Queries we will discuss why calculated fields in Access tables can be restrictive and why calculations are usually better placed in queries. We will also cover when storing calculated values may be appropriate, calculated fields and portability, self-referencing employee relationships, subform filtering quirks, using AI responsibly, numeric versus text identifiers, cloud storage risks, recordset tests, and SQL string concatenation in VBA. Diego from Newark, New Jersey (a Platinum Member) asks: I'm building an order database and noticed Access lets me create a field that automatically calculates an extended price from quantity and unit price. I've heard you say you don't recommend calculated fields in tables and even call them evil. Are they actually bad, and when would it be okay to use one? PrerequisitesLinksRecommended CoursesUp Next
Keywords TechHelp QQ Quick Queries, Access calculated fields, calculated field data type, calculated fields in tables, calculated query fields, table calculations vs queries, Access query expressions, denormalization, storing calculated values, Access calculated field limitations, DAO BOF EOF, recordset RecordCount
More InformationTranscript Have you ever seen the calculated data type in an Access table and thought to yourself, "Hey, that looks handy." Well, it can be handy, but it can also paint you into a corner later.
Welcome to another TechHelp Quick Queries video brought to you by Access Learning Zone. I'm your instructor, Richard Rost.
Today, we're going to talk about the calculated fields in Microsoft Access tables, why I generally recommend putting your calculations in queries instead, and my thoughts on that subject.
In addition to that, we've got answers to questions from YouTube comments, my forums, emails, and lots of other stuff.
All right, let's get to it.
Today's first question comes from Diego in Newark, New Jersey, one of my Platinum members. Diego says, "I'm building an order database and noticed Access lets me create a field that automatically calculates an extended price from quantity and unit price. I've heard you say that you don't recommend calculated fields in tables and even call them evil. Are they actually bad, and when would it be okay to use one?"
Well, Diego's talking about my Evil Access Stuff page, and on here, I do have... where are they? Yeah, right there. "Calculated fields in tables. Use calculated query fields instead. Tables shouldn't contain calculations." That's my opinion, and I'm sticking to it.
Let's talk about why.
Now, calling them evil is a little dramatic, of course, but it's the dramatic stuff that tends to stick in my students' brains. Now, Access isn't going to burst into flames because you put a formula in a table, but it's still a good question because Access does let you create a field with the calculated data type right in the table. You give Access a formula, and it automatically works out the result for every record.
For example, if an order detail record has quantity and unit price, you could add an extended price calculated field with a formula like quantity times unit price right in the table design. Now, that sounds handy, and sometimes it is, but just because Access lets you put a calculation in a table doesn't necessarily mean that's the best place for it.
Now, my general philosophy is very simple. Tables are for storing data. Queries are for calculating, filtering, sorting, and combining that data.
Now, let's all make sure we're on the same page here. A calculated table field is a field whose data type is literally calculated. Instead of entering a normal value into that field, you provide an expression, which is just Access-speak for a formula.
So, in the Order Detail table, you might have quantity, unit price, and extended price, and those are all fields in the table. The extended price expression could be quantity multiplied by unit price.
A customer buys three widgets at $10 apiece, Access shows $30 in the extended price field. Change quantity to 4, Access gives you 40. Nobody is supposed to type directly into the extended price field because it's the answer, not the input. And that's the basic appeal of calculated table fields.
The issue isn't that this calculation is wrong. The issue is whether the table is the right place to permanently define that calculation for your whole application.
So, why do I put these on my Evil Access Stuff list? Well, evil is my fun little shorthand for Access lets you do this, but there's usually a better way. It's not illegal. The Access police aren't going to show up at your house, well, at least not for this. But the real concern is database design.
A table is the foundation of your database. It should primarily describe the facts you're storing: what was ordered, when it was ordered, how many were ordered, what the price was. The calculation is application logic. It's a rule for turning those facts into an answer. Queries are designed to do exactly that kind of work.
When you keep the calculations in queries, you can change the calculation, make another version of it, use it in a report, combine it with other tables, without changing the underlying table design.
So, calculated fields aren't automatically bad. They're simply more restrictive than many beginners realize.
The biggest limitation calculated table fields have is that they only work with fields from that same table. Our quantity times unit price example works because both pieces of information are right there in the Order Detail table, nice and simple.
But real-world calculations often don't stay simple for very long. Maybe the sales tax rate depends on the customer's state. Maybe the current price comes from the Product table. Maybe a discount comes from a pricing table based on the customer's membership level. Maybe a commission depends on the salesperson and the product category.
So, now you can see how you start to deal with information stored in different related tables, which is exactly what a relational database is supposed to do.
Now, a query can bring together CustomerT, OrderT, OrderDtlT, ProductT, perhaps a TaxRateT, bring them all together in a query. And then the query can calculate the value using all of that information. A calculated table field in the Order Detail table can't reach across the database like that. It's stuck in its own little room. Queries have the keys to the whole building.
Even when your calculation starts out simple, it might grow later. Today, extended price might just be quantity times unit price. Tomorrow, you might need a report that includes a discount. Next month, you might need a different version that includes tax. And then accounting wants the pre-tax amount, and then sales wants the customer-facing total.
And then, if the formula lives in the table, you've got one table-level calculation trying to serve every possible purpose. That can get difficult fast.
With queries, you can make an Order Detail query for your standard calculations. Then you can make an invoice query that adds tax and shipping. You can make a sales commission query that calculates commission. So, every query can provide the answer needed for that job.
And you can also use the query as the record source for multiple forms and reports. That way, the report gets its data from this query, and this other form gets its data from that table, and blah, blah, blah.
And as your calculations become more sophisticated, queries generally give you more room to work with functions and expressions than calculated table fields do. And if I know I'm probably going to end up putting something in a query anyway, I just prefer to start there in the first place.
Another common misconception is that putting the calculation in the table makes the database faster. Not necessarily. A calculated table field is not the same as pre-computing a value and saving that result as ordinary data. And calculated table fields can't be indexed, so they don't give you an automatic performance magic wand.
For everyday calculations like quantity times price, the difference normally isn't worth worrying about in a typical Access database. Just let the query calculate it.
Now, there are absolutely situations where storing a calculated result in a normal table field makes sense. Maybe you've got a very expensive aggregate calculation over a huge amount of data. Or maybe the database has far more reads than writes. Or maybe you just have to preserve exact historical values at the time of the transaction.
But that's a separate design decision. In that case, you're saying, "I want to calculate this value and save it." You're not saying, "I want an Access calculated data type." So, don't confuse those two tools. They solve different problems. The calculated table field shouldn't be treated as a performance feature.
For simple calculations like quantity times unit price, I'd use a query. A query provides the same result while keeping the calculation separate from the table.
Now, one example of when it's good to store a value is suppose you've got hundreds or thousands of order records and you're constantly displaying monthly sales totals. You calculate that every single time by adding up all the orders for that month. But if those older months aren't changing anymore, you might calculate the total once and store it in a regular field. Call it something like monthly sales total.
Now, Access can just read that one value instead of adding up thousands of records every time. That's called denormalization. I've actually got a whole separate video on when you want to do that. I'll give you a link in just a minute.
And sometimes we do denormalize our tables deliberately for performance. But that's still a normal data field. It's a normal stored field. It's not the calculated data type that we're talking about here.
Now, whenever I do one of these videos, I always do some research, and I have seen some reports. I haven't verified this myself, but I have seen some reports that when you're dealing with millions of records, you may see a slight improvement in performance using calculated table fields.
But my opinion is, if you've got a database with millions of records, you probably should be using SQL Server anyway. And then that becomes moot. So, performance can be a minor legitimate reason to consider a calculated table field. But as always, I would test it with your actual data after making a complete backup, of course.
Another consideration is portability. Calculated table fields are an Access-specific feature. So, if your little Access database stays a little Access database forever, that might be just fine. But as I've seen over the past 30 years, databases grow. Even databases that you didn't think would grow. When your company grows, it's going to grow.
Maybe several people start using it. Maybe you move the tables to SQL Server. Maybe you hire another developer who's got to work with it and looks at you like, "What is this mess?" I've been that developer. I've gone into companies before, and I'm like, "Who did this?" I've got to be very careful, though, because the guy I'm talking to might be the guy that did that. So, you've got to tread lightly in that case.
But maybe you'll upgrade. Maybe you'll build a web application around it. Who knows? And when that happens, you can't assume that an Access calculated field will nicely move over and behave in the new system. It might need to be rebuilt as a query, a view, application code, or something else.
Now, don't over-engineer a database for a future that might never happen. If you're tracking your baseball card collection at home, SQL Server migration probably isn't your number one worry. But keeping tables focused on stored facts and putting calculations in queries is usually a cleaner, more portable habit from the beginning.
So, don't lose sleep over thinking about migrating your database in the future. But learn some of the best practices now so you don't shoot yourself in the foot. I've shot myself in the foot many times because I didn't know any better. So that's why I'm trying to teach you guys this stuff.
So, when's it okay? Is it ever okay to use calculated table fields? Yeah, sure. Our quantity times unit price example. If both values are in the same record, the formula is simple, no one will ever need to override the result, and that extended price is useful almost everywhere you use the table, then a calculated field could be reasonable.
If you're staying entirely inside Access, you understand the limitations, go ahead. I won't send the Access police to your house. Your database probably won't explode, probably.
But the important part is that you know you're choosing it for a reason, not just because the calculated option happens to be sitting there in that data type list and looks tempting.
My preference would still be to create an extended price field in a query because it leaves me more options later. But a simple calculated table field, it's not a database crime. It's just a tradeoff. And as long as you understand what you're giving up and what kind of trouble you're possibly getting into, you can make an informed decision.
So, in a nutshell, calculated fields in Access tables are not evil in the literal sense. They're not going to cause plagues of locusts and that kind of stuff. They are a legitimate feature, and they work fine in certain simple, same-record calculations.
But my standard rule remains: tables store data, queries perform calculations. Queries can use multiple tables, handle more sophisticated expressions, give you different calculations for different purposes, and keep your application logic separate from the raw data. And that's a big one for me.
Queries also give you a cleaner path if your database grows beyond Access someday. So, don't be afraid of calculated table fields. Just don't use them automatically. Don't use them all the time. Start with a query unless you have a good, specific reason to put that formula in the table.
Trust me, it's a habit that will save you headaches later.
If you want to learn more, here's a video on calculated fields and how to make them in queries and forms. You can also do them in reports. In the extended cut for that video for the members, I do go through a couple of examples of using calculated table fields.
This video talks about storing a value versus calculating it on the fly. That's the discussion we had a few minutes ago. When is it okay to store a value in the table that could be calculated?
And here's that video on denormalizing your data when this makes sense. So, check these out. These are all free videos. They're on my YouTube channel, they're on my website, and yeah, they're all free. So, check them out.
Let's see what else we got in the mailbag today.
I had a new thread in my website forums. We've got Amir building an employee database where one employee can report to multiple supervisors, and a supervisor can have multiple direct reports or assistants. He's got a many-to-many junction table working, but the sticking point is displaying the employee names instead of just a bunch of IDs in his supervisor and subordinate subforms.
And this is a good one because the trick is realizing that both sides of the relationship point back to the same employee table. And Donald has the right approach with one junction table and two subforms, one showing who the employee reports to and one showing who reports to them.
Then each subform gets a query that joins the appropriate ID back to the employee table so you can display the person's full name. And Kevin also pointed out that if you ever need both names in one query, just add the employee table twice. And Access will call the second copy something like EmployeeT_1 or something like that.
Yeah, here's Kevin's other comment. You'll get Employees_2 or whatever, or _3. And then Thomas added a bunch of stuff. He owes me two cents for talking about his database again, which is a pretty cool database, by the way. I do have to say he's added a lot of stuff to this one.
But yeah, this came up. It's a pretty cool thread. I'll put a link to this one down below. You can read the whole thing yourself if you want to learn more.
Next up, I got Raymond. He ran into a weird one. He had a subform that kept filtering itself based on the parent form, even though Link Master Fields and Link Child Fields were blank. The subform showed everything when opened by itself. But as soon as the parent form was bound, the records disappeared, almost like Access remembered an old link that wasn't there anymore.
And this is definitely one of those Access-being-Access situations. Normally, if the Link Master Fields and Link Child Fields are blank, that means the subform shouldn't be filtering based on the parent. And a table relationship by itself shouldn't secretly do that either.
And Raymond checked the obvious stuff, even recreating the subform control, and that didn't fix it. So, at that point, I'd suggest some old design baggage or corruption. It's a database he's been working on for years.
Matt had a good suggestion, and that's to use Save As Text so you can inspect what Access actually stored. And then I'd also try a decompile followed by a compact and repair. Since making the parent unbound fixed it, I'd call this a quirk unless you can reproduce it consistently.
So, Access has a lot of those weird behaviors.
Next up, I wanted to just briefly go over an email that I've received. I've actually gotten this from a couple of people over the last month or two. This one's from Alan in Detroit, Michigan, a former Platinum member.
He said, "I've really enjoyed your Access classes and I'm learning a lot from them, but I've decided to cancel my membership. Lately, I've been using AI for most of the Access work I need to do. I can describe what I want, and it gives me the queries, VBA code, or steps to follow, so I don't feel like I need to spend as much time learning how to do everything myself anymore. Thanks for all the help over the years. I just wanted to let you know why I was canceling."
I've actually, like I said, gotten a few messages like this recently, and I completely understand. I use AI all day long myself. It's an incredible productivity tool, but I wouldn't confuse "AI can do this for me" with "I don't need to understand this anymore."
I look at AI like a calculator. A calculator means you don't have to do long division by hand every day, but you still need to understand math.
I always say you should treat AI like a really capable junior assistant or an intern. Give it work, review what it gives you, and I sometimes have to say, "No, that's not how Access works."
And if you don't understand Access yourself, you might not recognize when the AI gives you something that's subtly wrong. So, I absolutely do use AI. I do. I let it write some of the code that saves me a lot of time.
I already know how to write recordset loops. So, I might say, "All right, I need a recordset loop that goes through these customers with this condition, and I need to do that with it." Instead of spending 20 minutes writing it myself, I can have it spit it out for me in 15 seconds.
So, outsource some of the code writing, that's fine, but don't outsource your understanding along with the work. The people who know their subject are going to get far more out of AI because they know what to ask for, and they can recognize a bad answer. And they know how to fix it when something doesn't work.
AI is a force multiplier. It's not a replacement. It's garbage in, garbage out. The more you know going in, the more useful it becomes when it gives you something out.
So, I love AI. I use it a lot, but don't have it replace your thinking for you. Still understand what you're working with.
All right, let's head over to the YouTubes.
We got Kevin pointing out that you can also use the Int function to chop off decimals. But there's an important difference between Int and Fix when you're dealing with negative numbers.
And yes, I mentioned this in the video. For positive numbers, Int and Fix will give you the same result. But with negatives, Int always rounds down. So, negative 109.9 becomes negative 110. Fix chops toward zero. So, 109.9 becomes 109. Negative 109.9 becomes negative 109.
That's why I used Fix in this video. So, if you literally want to chop off the decimal portion without any rounding, Fix is the better choice.
And the example that I give in this video is working with sheets of financial data. And for every debit, you've got negative numbers on there. I want to just chop off that decimal point. I don't want to round it down.
All right, next up, we got John, who says my pronunciation of the number was very American-centric because in British English, you'd normally say 15,110, whereas I said 15,110.
So, yeah, this is a difference between American English and British English. John's absolutely right. I had to look this one up. I was always taught in school and in college and in programming books and stuff that I've read that you don't say "and" inside a whole number.
So, in American English, you'd say 15,110 and 15 cents. But in British English, 15,110 is standard.
So, it's just one of those little differences between American and British English. You guys add an "and," we throw out a "u" from color and armor, and somehow civilization continues.
So, thank you, John, for correcting me. And this is one of those things that I love learning from you guys, too. I actually had to look this one up.
The Cambridge British grammar guidance gives a number like 625 dollars and 15 cents. In American English, you'd say 625 dollars and 15 cents. And in British English, you'd say 625 dollars and 15 cents.
So, John's comment is absolutely legitimate. The British are apparently much more generous with their "ands" than we Americans are.
Next up, we got B Jones. He says he understands my rule about storing phone numbers as text but points out that numeric fields can also store a typical phone number just fine.
And sure, you can store a phone number as a number, but my rule is about what the value represents, not what characters happen to be in it. You're never going to add two phone numbers together or calculate the average of your phone numbers. So, there's really no benefit to making it numeric.
Text will preserve leading zeros, which happens with things like Social Security numbers, handles extensions, plus signs for international numbers, and doesn't care if the format changes later.
Same thing with ZIP codes, account numbers, part numbers, all that stuff. If it's an identifier and you're not doing math with it, I store it as text. Text is a lot easier to work with. Give me the left three characters. Give me the right three characters.
Plus, I don't know if you're old enough to remember, but back in the day, my grandma used to give me her phone number, and it had letters in it because people would store the letters off the phone. What happens if you've got 1-800-FLOWERS? Do you want to stop and grab your phone and, okay, F is what, 6, L is... no, just type in FLOWERS.
So, that's why I store it as text. If it's not something I'm going to be doing math on, text. But that's my rule. You can do whatever you want. It's your database. That's the beauty of doing it yourself. They're your Legos. You build whatever you want with them. I just give you my opinions and stuff.
Next up, this guy is asking how to use an Access database directly from Google Drive without getting all those errors. The answer is, don't. That's actually the whole point of the video that you're commenting on.
Google Drive is fine for storing or transferring an Access database, but don't open and run the database directly from the sync folder, whether it's Google Drive, Dropbox, OneDrive, any of those.
I've talked about this in a million videos. Now, years ago, I used to do this myself between my home and my office when I actually had an office that I'd take 20 minutes to drive to. I'd copy my database, which is a relatively small database file, maybe 50 or 60 megs. I'd copy it up to Google Drive, drive to the office, and then I'd copy it down to my local workstation there, work on it, then copy it back up when I was done.
You can save it on Google Drive. But don't run it from Google Drive. You're just begging for corruption. When it tries to sync, if that database file is open, it's not going to be pretty. It might work for a while, but it's great until it's not.
If it's just you, if it's one person, then you're careful. Okay, if you run the database live off Google Drive, especially with multiple users, you are begging for corruption. If you need simultaneous remote access or multiple users, that's when you want to start looking at SQL Server.
Next up, we've got Simon, who also agrees that postal codes should be stored as text, especially since countries like Canada and the UK use letters and numbers. He also mentioned something I didn't know. Canada apparently has a special postal code for kids writing to Father Christmas. That is awesome.
But yeah, that's another great example of why postal codes, ZIP codes, all that stuff belong in text fields. They're identifiers, not numbers. When you start dealing with international stuff, you've got letters, spaces, leading zeros, and apparently some Christmas magic.
All right, next up, we've got R-Tat1 pushing back on something I said in the BOF and EOF video. He says RecordCount may not initially give you the correct total number of records, but it should still reliably tell you whether the recordset is empty.
And he's right. That's a good catch. I should make a distinction here. With a DAO recordset, RecordCount equals zero is a perfectly valid way to determine that you've got an empty recordset.
The problem with RecordCount is using it as an actual count. You might open a recordset containing 500 records and initially get one until you MoveLast and force Access to visit all of them.
So, RecordCount greater than zero is fine for "Do I have records?" I still prefer checking BOF and EOF because that's explicitly what I'm testing. But your method is perfectly valid, so thanks for keeping me honest.
It's just a matter of I wouldn't want future me or someone else seeing it, seeing RecordCount, and thinking that it's an actual record count. But if you're just using it for a count to know if it's zero, then yeah, you could get away with that. In fact, in one of my databases, I actually wrote a HasRecords function that does something similar.
So, yeah, there's lots of ifs, thens, and buts and other buts. But you're right.
All right, continuing on with the BOF and EOF video, he also asks why I check both BOF and EOF to see if a recordset is empty, since a newly opened recordset starts on the first record if there is one. Wouldn't just checking EOF be enough, or BOF, either one?
And yes, you're absolutely right. Immediately after you open a recordset, if it has records, Access should put you on the first one. So, at that moment, just checking EOF or just checking BOF is enough to tell whether the recordset is empty.
The reason why I always teach BOF and EOF is because I want my students to get in the habit that's safe, regardless of whether they've used the recordset or where that recordset is later.
Because once you start navigating through it, EOF by itself or BOF by itself doesn't tell you that the recordset has records or not. EOF by itself could simply mean you moved past the last record, or BOF could mean that you moved before the first record. But when both BOF and EOF are true, that's the definitive condition that there are no records in that recordset.
So, you're correct. There are shorter ways to do it immediately after opening the recordset if you do it immediately. This is just one of those best-practice habits that I teach beginners because six months later, you're going to use the same test on a recordset that's already been moved around in, and I don't want you wondering what happened.
So, check both, and you don't have to think about it. Just get in the habit of always checking both if you want to know whether there are records or not. There's a method to my madness. I've been bitten by this stuff before. That's why I try to teach you guys my best practices, at least.
But yes, good question, and you are correct.
Next up, we got Satya Bahn watching Access Beginner 1 and wondering why, when people build SQL statements in VBA, they use ampersands and quotes around form fields or variables instead of just putting the field name directly in the SQL.
Well, this is really what's called string concatenation, and if you're still on Access Beginner 1, don't worry if this looks like hieroglyphics right now. You really don't even need this yet.
Later, when you start building SQL statements in VBA code, the SQL processor can't magically know what a VBA variable or a control on a form contains. So, you have to build the string dynamically and then put the actual value into it. And the ampersand is what concatenates, or glues, those pieces together.
Now, another big thing is the EmployeeID. If that's a number, then you don't need to put quotes around the value. If you're looking for a text value like a last name, then SQL needs the quotes around all that text. And you have to be careful that there aren't double quotes inside the text. That's a whole different level of escaping characters.
Dates have their own delimiters too. They use little pound signs. So, once you understand concatenation, all those crazy-looking ampersands and double quotes start making a lot more sense.
Go watch this video on concatenation and watch this video where I cover the single quotes, the double quotes, the double double quotes, and all that stuff. So, there's lots more to it, but these videos explain it.
All right, hey, if you're still with me, hit that Like and Subscribe button if you haven't already. If you like my videos, it helps more people find my channel, and I'll be forever grateful.
Don't forget to stop by my website and check out my What's New. I've got all kinds of new stuff. I always post new videos and templates and updates and random bits of Access goodness here and there.
And don't forget to check out my Captain's Log, where I post all kinds of random weirdness. Like, I just added a sticky nav bar to my website. It only took 24 years, but I finally have one.
What's a sticky nav bar, you ask? Well, that's when the nav bar up top here stays sticky. Watch when you scroll down. Ooh, I finally joined the late '90s. My website isn't in the early '90s anymore.
And the reason why is because I built this whole site with HTML tables. And just to redesign the whole thing would be... it would take a lot of work. But I finally got those distracting pennies, and I got on Big and I got video.
Oh, and I made it so videos can turn autoplay on and off too. Oh, you've got to be logged in for that. So, yeah, there's lots of cool stuff on my website.
I also wrote about the Heisenbug, a bug that doesn't exist until you see it. Oh, someone's beaming in. Hold on, Tribbles.
I also wrote about my journey to go see the recent eclipse in Spain and about how I got clouded out. So, that was kind of a bummer. But yeah, that's all in my Captain's Log.
And don't forget to stop by the merch store. Pick up a T-shirt, pick up a mouse pad, a coffee mug, get a copy of my book if you haven't already.
Stop by the forums if you want to ask questions. I've got lots of great moderators and advanced students that love helping people out.
If you need more help, if you're looking for a tutor or a developer, someone to work with, check out my Access Developer Network. And make sure you're on my mailing list so that every time I release something new, you get an email. And I won't spam you much.
But there you go. That is going to do it for your TechHelp Quick Queries for this week. I hope you learned something. Live long and prosper, my friends. I'll see you next time. Intro In today's Quick Queries we will discuss why calculated fields in Access tables can be restrictive and why calculations are usually better placed in queries. We will also cover when storing calculated values may be appropriate, calculated fields and portability, self-referencing employee relationships, subform filtering quirks, using AI responsibly, numeric versus text identifiers, cloud storage risks, recordset tests, and SQL string concatenation in VBA. Quiz Q1. What is the general recommended role of tables in an Access database?
A. Store raw facts and data
B. Perform all calculations and reporting
C. Store only temporary query results
D. Replace forms and reports
Q2. What is the general recommended role of queries in an Access database?
A. Store permanent transaction records
B. Calculate, filter, sort, and combine data
C. Replace all table relationships
D. Store user interface settings
Q3. Which is a good example of a simple calculated field expression?
A. [Quantity] * [UnitPrice]
B. [CustomerName] + [OrderDate]
C. [ProductID] = [CategoryID]
D. [OrderID] / [CustomerID]
Q4. Why are calculated fields in tables more restrictive than calculated fields in queries?
A. They can only use fields from the same table
B. They require VBA code to work
C. They cannot perform multiplication
D. They only work in reports
Q5. Why might a calculation be better placed in a query instead of a table?
A. A query can use fields from multiple related tables
B. Queries permanently store results faster
C. Tables cannot contain numeric fields
D. Queries eliminate the need for relationships
Q6. Which situation is most likely to require a query calculation rather than a calculated table field?
A. Extended price based only on Quantity and UnitPrice in the same record
B. Tax based on the customer's state in another table
C. Displaying a single text field
D. Entering a new customer name
Q7. What is a benefit of keeping calculations in queries?
A. Different queries can provide different calculations for different purposes
B. The calculation becomes impossible to change
C. Users can directly edit all calculated results
D. The query automatically indexes every expression
Q8. Is a calculated table field the same as calculating a value once and storing it as normal data?
A. Yes, they are exactly the same feature
B. No, they are separate design decisions
C. Yes, but only for text fields
D. No, because calculated fields only work in VBA
Q9. When might storing a calculated value in a normal field be appropriate?
A. When an expensive calculation must be repeatedly displayed and historical values no longer change
B. Whenever Quantity and UnitPrice are available
C. Whenever a field contains text
D. Only when Access does not support queries
Q10. What is denormalization in this context?
A. Deliberately storing a value to improve performance in an appropriate situation
B. Removing all primary keys from tables
C. Converting text fields into numeric fields
D. Deleting old transaction records
Q11. Why should calculated table fields not automatically be considered a performance feature?
A. They cannot be indexed and do not automatically provide a major speed improvement
B. They always make databases slower than VBA
C. They cannot calculate numeric values
D. They require a separate report for every calculation
Q12. What is a portability concern with calculated fields in Access tables?
A. They are Access-specific and may need to be rebuilt when moving to another platform
B. They cannot be copied between Access databases
C. They only work on one computer
D. They prevent tables from being backed up
Q13. When can a calculated table field be a reasonable choice?
A. When the calculation is simple, uses fields in the same record, and is useful nearly everywhere
B. When the calculation needs data from five related tables
C. When users need to override the calculated result regularly
D. When the database must be moved immediately to a web application
Q14. In a self-referencing employee relationship, what does it mean when both sides point back to the Employee table?
A. An employee can be related to other employees, such as supervisors and subordinates
B. The Employee table cannot have a primary key
C. Every employee must have the same supervisor
D. The database cannot use subforms
Q15. How can a query display employee names instead of only supervisor and subordinate IDs?
A. Join the appropriate ID fields back to the Employee table
B. Change all IDs to text fields
C. Delete the junction table
D. Store employee names in every relationship record
Q16. If a query needs to show both the supervisor name and subordinate name, what can be done?
A. Add the Employee table to the query twice
B. Use only one EmployeeID field
C. Remove the employee relationship
D. Convert the query into a calculated table field
Q17. If a subform appears filtered by its parent even though Link Master Fields and Link Child Fields are blank, what may be worth investigating?
A. Old design baggage, corruption, or hidden stored properties
B. Whether the primary key is numeric
C. Whether the form has a title
D. Whether the database has a report
Q18. What is Save As Text useful for when troubleshooting strange Access object behavior?
A. Inspecting what Access actually stored in the object definition
B. Converting every table into a text file permanently
C. Encrypting the database
D. Creating a SQL Server database
Q19. What is the recommended attitude toward using AI for Access development?
A. Use it as a productivity tool, but understand and review its output
B. Let it replace all understanding of Access
C. Never use it for code or queries
D. Use it only to create table relationships
Q20. Why is subject knowledge still important when using AI?
A. You need to recognize incorrect answers and know how to fix problems
B. AI only works with paper databases
C. Access prevents AI-generated code from running
D. AI can only write comments, not code
Q21. What is the difference between Int and Fix for negative numbers?
A. Int rounds down, while Fix removes the decimal portion toward zero
B. Fix rounds down, while Int always rounds up
C. They always return identical results
D. Int works only with positive numbers
Q22. If you want to remove the decimal portion without rounding, including for negative values, which function is generally preferred?
A. Fix
B. Int
C. Round
D. Format
Q23. Why should phone numbers generally be stored as text rather than numbers?
A. They are identifiers, not values used for math
B. Access cannot display numeric phone numbers
C. Text fields cannot contain digits
D. Numeric fields cannot be searched
Q24. What is one advantage of storing phone numbers, postal codes, and account numbers as text?
A. Text can preserve leading zeros and support letters, spaces, and symbols
B. Text automatically calculates totals
C. Text fields are always indexed
D. Text fields prevent duplicate values
Q25. What is the recommended way to use an Access database with Google Drive, Dropbox, or OneDrive?
A. Store or transfer copies there, but run the database from a local drive
B. Run the live shared database directly from the sync folder
C. Keep the database open while several users sync it
D. Use a sync folder as a replacement for a database server
Q26. Why is running a live Access database directly from a sync folder risky?
A. Synchronization conflicts can lead to database corruption
B. Queries cannot run from cloud folders
C. Forms are automatically deleted
D. Access cannot open files larger than one megabyte
Q27. What is a valid use of RecordCount immediately after opening a DAO recordset?
A. Checking whether RecordCount equals zero to determine whether it is empty
B. Reliably getting the total number of records without moving through the recordset
C. Determining the current form filter
D. Identifying the primary key field
Q28. Why might RecordCount not initially provide the actual total number of records in a recordset?
A. Access may not count all records until the recordset is moved through, such as with MoveLast
B. RecordCount only works with text fields
C. RecordCount always returns a negative number
D. RecordCount is only available in reports
Q29. Why is checking both BOF and EOF a safe habit when determining whether a recordset is empty?
A. Both being true definitively indicates that the recordset has no records
B. BOF and EOF both count the number of records
C. It automatically moves to the last record
D. It prevents all query errors
Q30. When building a SQL statement in VBA, what does the ampersand character do?
A. Concatenates, or joins, pieces of a string together
B. Adds a numeric value to a table
C. Creates a table relationship
D. Converts text into a date
Q31. How should a text value generally be delimited when inserted into a dynamically built SQL statement?
A. With quotes
B. With square brackets only
C. With parentheses only
D. With no delimiters
Q32. How should a date value generally be delimited in an Access SQL statement?
A. With pound signs
B. With quotation marks only
C. With commas
D. With braces
Answers: 1-A; 2-B; 3-A; 4-A; 5-A; 6-B; 7-A; 8-B; 9-A; 10-A; 11-A; 12-A; 13-A; 14-A; 15-A; 16-A; 17-A; 18-A; 19-A; 20-A; 21-A; 22-A; 23-A; 24-A; 25-A; 26-A; 27-A; 28-A; 29-A; 30-A; 31-A; 32-A
DISCLAIMER: Quiz questions are AI generated. If you find any that are wrong, don't make sense, or aren't related to the video topic at hand, then please post a comment and let me know. Thanks. Summary In today's Quick Queries video, I am answering a collection of questions about Microsoft Access design, VBA behavior, database troubleshooting, AI, and a few common misconceptions that come up frequently in comments, emails, and forum discussions.
The first topic is calculated fields in Access tables. Access gives you a Calculated data type that lets you define an expression directly in a table. For example, an Order Detail record might contain Quantity and UnitPrice, and you could add a calculated field for ExtendedPrice that automatically multiplies those two values together.
At first glance, that seems convenient. If a customer orders three items at $10 each, the calculated field displays $30. If the quantity changes to four, the result changes to $40. Nobody needs to type the extended price because it is derived from the other values.
Calculated table fields are not literally evil. Access will not break simply because you use one. I call them evil because I want students to remember that Access may let you do something that is not necessarily the best long-term design choice.
My general database design rule is simple: tables store data, while queries calculate, filter, sort, and combine data.
Tables should focus on the facts that belong in the database. In an order system, those facts may include the customer, order date, quantity ordered, product, and price at the time of the sale. A calculation is usually business logic. It is a rule that turns stored facts into an answer. Queries are built specifically to handle that kind of work.
A calculated field in a table works best when the calculation is simple and every value involved comes from the same record in the same table. Quantity multiplied by UnitPrice is a reasonable example because both pieces of data are available in the Order Detail record.
However, real calculations often become more complicated over time. Perhaps tax depends on the customer's state. Perhaps the price comes from the Product table. A discount may depend on a membership level, a pricing schedule, or a product category. Commission might depend on the salesperson, the product, and the customer's status.
Once a calculation needs information from related tables, a calculated field in one table becomes restrictive. It cannot reach across the database and use data from the Customer, Product, Tax Rate, or Pricing tables. A query can join all of those tables together and calculate the appropriate result.
This is one of the biggest reasons I prefer query calculations. A query can bring together the information needed for a particular job. One query can calculate a basic extended price. Another can calculate invoice totals with tax and shipping. A third can calculate commissions. Accounting may need a pre-tax amount, while sales may need a customer-facing total. Each query can provide the version of the calculation appropriate for that purpose.
If you put one calculation directly in the table, you are trying to make one table-level formula serve every possible need in the entire application. That can become difficult quickly.
Queries also make it easier to reuse calculations in forms and reports. You can use a query as the Record Source for a report, form, subform, or another query. This keeps the table focused on raw stored data while allowing each object to display the calculated information it needs.
Another issue is flexibility. A calculation that begins as Quantity multiplied by UnitPrice may later require discounts, tax, special pricing, promotions, rounding rules, or other business logic. Queries generally provide more room for sophisticated expressions and functions than calculated fields in tables do.
Some people believe that putting a calculation in a table automatically makes the database faster. That is not necessarily true. A Calculated data type is not the same as calculating a value once and storing it as ordinary data. Calculated table fields also cannot be indexed, so they are not a magic performance solution.
For a normal calculation such as Quantity multiplied by UnitPrice, performance is usually not something you need to worry about in a typical Access database. Let the query calculate it when needed.
There are situations where it makes sense to calculate a result and store it in a regular table field. This might happen when a calculation is very expensive, when the database contains a large volume of data, when older records no longer change, or when you must preserve the exact historical value that existed at the time of a transaction.
For example, suppose you have a very large number of order records and regularly display monthly sales totals. If prior months are closed and will not change, you might calculate a monthly total once and store it in a normal field. That way, Access can retrieve a stored total instead of repeatedly adding thousands of transactions.
That is a design technique called denormalization. It can be useful when applied deliberately and carefully. However, it is different from using the Access Calculated data type. In that situation, you are choosing to store a calculated result as normal data for a specific business or performance reason.
There have been reports that calculated fields in tables may provide minor performance benefits with extremely large datasets. I have not personally tested every possible situation, and I would always recommend testing with your actual data after making a complete backup. However, if you are working with millions of records, you may be at the point where SQL Server is a better back end than an Access table.
Portability is another consideration. Calculated table fields are an Access-specific feature. If your database remains a small personal Access database forever, that may not matter. But databases often grow beyond their original scope. More users may begin using them. Tables may eventually move to SQL Server. A web application may be built around the data. Another developer may need to maintain the system.
When that happens, an Access calculated field may not transfer cleanly. It may need to be rebuilt as a SQL view, query, stored procedure, or application code. You should not over-engineer a small database for a future that may never happen, but keeping tables focused on stored facts and putting calculations in queries is generally a cleaner and more portable habit.
So when is it acceptable to use a calculated field in an Access table? If the calculation is simple, all inputs are in the same record, nobody will ever need to override the result, and the calculation is useful almost everywhere the table is used, then it can be reasonable.
For example, an ExtendedPrice field based only on Quantity and UnitPrice could be appropriate in a simple Access-only application. It is not a database crime. It is simply a tradeoff.
Even then, my preference is usually to create the calculated field in a query. That gives me more flexibility later. My standard rule remains that tables store data and queries perform calculations. Start with a query unless you have a clear reason to put the calculation directly in the table.
I also discussed a question about a self-referencing employee relationship. This situation occurs when employees can report to multiple supervisors and supervisors can have multiple direct reports or assistants. That is a many-to-many relationship.
The correct design is to use a junction table. The junction table stores two references back to the Employee table: one for the employee and one for the supervisor. Each record represents a reporting relationship.
The challenge is that you do not want forms and subforms showing only employee ID numbers. You want to display employee names. Since both sides of the relationship point back to the same Employee table, the solution is to use queries that join the junction table back to the Employee table.
You can create one subform that shows the supervisors an employee reports to. You can create another subform that shows the employees who report to that employee. Each subform uses a query that joins the appropriate ID field back to the Employee table so that the employee's name can be displayed instead of just an ID.
If you need both the employee name and supervisor name in a single query, you can add the Employee table twice. Access will assign an alias-like name to the second copy, such as EmployeeT_1. This allows one instance of the table to provide the employee name and the other instance to provide the supervisor name.
Next, I addressed a strange issue involving a subform that appeared to filter itself based on its parent form even though the Link Master Fields and Link Child Fields properties were blank.
Normally, if those two properties are blank, a subform should not be filtered by the parent form. A table relationship by itself should not secretly apply filtering to a subform either.
In this case, the subform showed all records when opened by itself, but records disappeared when the parent form was bound. Recreating the subform control did not resolve the issue.
This is one of those situations where old design baggage, corruption, or an unusual Access quirk may be involved. In a database that has been developed for years, Access can occasionally retain unexpected information in the object definitions.
A useful troubleshooting technique is Save As Text. This allows you to inspect the underlying text representation of forms, reports, queries, and other Access objects to see what Access actually stored. It can reveal settings that are difficult to find through the normal property sheet.
I would also try decompiling the database and then performing a Compact and Repair. If making the parent form unbound resolves the problem, I would treat it as a likely quirk unless the behavior can be reproduced consistently in a clean sample database.
Access is a powerful tool, but it does have occasional odd behaviors that can be difficult to explain. When that happens, isolate the problem, test the obvious properties, inspect the object definition if necessary, and consider rebuilding the affected object in a clean database.
Another topic was the growing use of AI for Access work. Some people have said they are relying on AI to create queries, VBA code, and instructions, so they feel less need to learn Access themselves.
I understand that completely. I use AI regularly too. It can be an excellent productivity tool. It can save time writing routine VBA procedures, help draft SQL statements, suggest approaches to a problem, and assist with troubleshooting.
However, I do not think that "AI can do this for me" means "I no longer need to understand this."
I compare AI to a calculator. A calculator saves you from doing long division by hand, but you still need to understand the math well enough to know whether the answer makes sense.
The same principle applies to Access and VBA. Treat AI like a capable junior assistant or intern. Give it a task, review the result, and be prepared to correct it. AI can provide code that looks convincing but is subtly wrong for Access, DAO, VBA, SQL syntax, or the particular structure of your database.
For example, I may already know how to write a DAO recordset loop. Instead of taking twenty minutes to write the routine from scratch, I can describe what I need and let AI generate a starting point. But I still need to understand recordsets, fields, conditions, error handling, and the intended logic well enough to review what it produces.
The people who understand their subject well will get more value from AI. They know how to ask better questions, recognize bad answers, and fix problems when the generated result does not work.
AI is a force multiplier, not a replacement for understanding. The better your foundation in Access, VBA, SQL, and database design, the more useful AI becomes.
I also clarified the difference between the Int and Fix functions in Access VBA.
For positive numbers, Int and Fix often appear to do the same thing. Both can remove the decimal portion of a value. For example, a positive value such as 109.9 becomes 109 with either function.
The difference matters with negative values. Int always rounds down toward negative infinity. Therefore, a value such as negative 109.9 becomes negative 110.
Fix removes the decimal portion by moving toward zero. Therefore, negative 109.9 becomes negative 109.
If you are working with financial data and want to remove the decimal portion without rounding the number further away from zero, Fix is often the better choice. This is particularly important when your data contains negative debit amounts.
I also discussed differences between American and British English when reading whole numbers aloud.
In American English, I was taught not to use the word "and" inside a whole number. For example, I would normally say "fifteen thousand, one hundred ten" and then use "and" before a decimal or fractional amount, such as "fifteen thousand, one hundred ten dollars and fifteen cents."
In British English, it is common to include "and" inside the whole number, such as "fifteen thousand, one hundred and ten."
Neither approach is a problem. It is simply one of the many differences between American and British English. Americans tend to leave out some letters in words such as color and armor, while British English often keeps them. Language continues to evolve, and it is always useful to learn from regional differences.
Another common question involves storing phone numbers as numeric data versus text.
A phone number may consist entirely of digits, but that does not make it a mathematical number. You do not add phone numbers together, calculate averages of phone numbers, or multiply one phone number by another. A phone number is an identifier.
For that reason, I recommend storing phone numbers as text. Text fields preserve leading zeros, support extensions, allow international prefixes such as plus signs, and make it easier to handle changes in formatting.
The same principle applies to ZIP codes, postal codes, Social Security numbers, account numbers, part numbers, invoice numbers, and similar values. If the value is an identifier rather than something you perform arithmetic on, store it as text.
Text also makes it easier to work with pieces of the value. You can extract the first few characters, the last few characters, an area code, an extension, or another segment without treating the value as a mathematical quantity.
Phone numbers may also contain letters. Toll-free numbers such as 1-800-FLOWERS are a familiar example. Storing phone numbers as text allows you to preserve the value as it is intended to be displayed and used.
The same rule applies especially well to postal codes. Countries such as Canada and the United Kingdom use postal codes containing both letters and numbers. They may contain spaces, leading zeros, and special formats. Canada even has a special postal code for children writing to Father Christmas. That is another reminder that postal codes are identifiers, not numeric values.
I also discussed why you should not open and run a live Access database directly from a Google Drive, Dropbox, OneDrive, or similar synchronization folder.
Cloud storage services are fine for storing a backup copy of an Access database or transferring a database file from one computer to another. They are not designed to safely handle a live multiuser Access database that is open while synchronization is taking place.
Years ago, I would copy a database to cloud storage, travel from one location to another, copy it down locally, work on it, and then copy it back to the cloud when I was finished. That can work if you are careful and only one person is using the file at a time.
What you should not do is open and run the database directly from the synchronized folder. If the database is open while the cloud software tries to sync it, especially if multiple users are involved, you risk corruption. It may seem to work until it suddenly does not.
If you need simultaneous remote access or multiple people working with the same data, that is when you should consider a proper client-server setup, such as Access forms and reports connected to a SQL Server back end.
Next, I clarified a point about DAO recordsets, BOF, EOF, and RecordCount.
RecordCount is valid for determining whether a recordset is empty. If RecordCount equals zero, then there are no records. That is a legitimate test.
The problem is using RecordCount as an immediate, reliable total number of records. Depending on the type of recordset and how it was opened, Access may not know the full count until you move through the records or use MoveLast. You might open a recordset that eventually contains hundreds of records but initially see a RecordCount value that does not reflect the final total.
If your only purpose is to determine whether records exist, checking whether RecordCount is zero can work. I still generally prefer to use BOF and EOF together because that explicitly tests whether the recordset is empty.
Immediately after opening a recordset, checking just EOF or just BOF may be enough. If the recordset contains data, Access should position you on the first record. If it is empty, both BOF and EOF are true.
However, once you start moving through a recordset, checking only BOF or only EOF can be misleading. EOF could mean the recordset is empty, but it could also mean you moved past the last record. BOF could mean the recordset is empty, but it could also mean you moved before the first record.
When both BOF and EOF are true, that is the definitive condition that the recordset contains no records.
I teach students to check both because it is a safe habit. Six months later, you may reuse the same test in a situation where the recordset has already been moved around. Checking both BOF and EOF keeps the intent clear and avoids confusion.
Finally, I answered a question about why VBA code that builds SQL statements uses ampersands, quotes, form controls, and variables instead of simply placing a field name directly inside the SQL statement.
This is string concatenation. The ampersand joins pieces of text together to form a complete SQL statement.
When VBA builds SQL dynamically, the SQL processor does not automatically know the current value of a VBA variable or a control on a form. You must construct the SQL text and insert the actual value into it.
The punctuation you need depends on the type of data. Numeric values generally do not need quotes. Text values do need quotes around them. Dates use pound signs as delimiters in Access SQL.
Text values also require care because the text itself may contain quotation marks or apostrophes. That is why building SQL can look confusing at first. Once you understand concatenation and data delimiters, the ampersands, quotes, and other punctuation begin to make sense.
If you are still early in your Access training, do not worry if dynamic SQL seems complicated. You do not need to master it immediately. Learn the basic concepts first, then move on to concatenation, SQL syntax, variables, form controls, and data types as you progress.
I also encourage you to visit my website for new videos, templates, updates, articles, and other Access resources. The forums are a good place to ask questions and get help from moderators and experienced students. If you need personal tutoring, development assistance, or a professional to work with on a database project, you can also find information about those services on my website.
You can find a complete video tutorial with step-by-step instructions on everything discussed here on my website at the link below. Live long and prosper, my friends. Topic List Calculated fields in Access tables
Why queries are better for calculations
Tables store data, queries calculate data
Same-table limits of calculated fields
Using multiple tables in calculated queries
Flexible calculations for forms and reports
Calculated fields and database performance
Storing calculated values versus calculating on demand
Denormalization for performance
Calculated fields and database portability
When calculated table fields are appropriate Article Microsoft Access allows you to create a Calculated data type directly in a table. At first glance, this seems convenient. If an order detail record contains a quantity and a unit price, you can create an ExtendedPrice field that automatically calculates Quantity multiplied by UnitPrice. Change the quantity, and Access updates the result.
This can work, but it is important to understand the tradeoffs before making calculated fields part of your table design.
A useful general rule is that tables should store facts, while queries should calculate, filter, sort, and combine those facts. In an order database, Quantity and UnitPrice are facts about an order item. ExtendedPrice is the result of applying a rule to those facts. For that reason, many database developers prefer to calculate ExtendedPrice in a query rather than define it as a calculated field in the table.
A calculated table field is not a normal field where you enter data. Instead, you enter an expression that tells Access how to derive the value. For example, an expression can multiply Quantity by UnitPrice. Users cannot directly edit the calculated result because it is determined by the other fields in the record.
The main limitation is that calculated fields in tables can only use fields from the same table. Quantity multiplied by UnitPrice works because both values are stored in the order detail record. However, real database calculations often require information from related tables.
For example, a sales tax amount might depend on the customer's state. A discount might depend on a membership level, product category, or pricing table. A commission might depend on the salesperson, the product, and the order date. These values may come from Customer, Product, TaxRate, Pricing, or Employee tables. A calculated field in the OrderDetail table cannot easily use information from all of those related tables.
A query can. A query can join the Order, OrderDetail, Customer, Product, and other related tables together. It can then calculate values using fields from all of them. This makes queries much more flexible for business calculations.
Calculations also tend to grow over time. An extended price might begin as quantity times unit price. Later, you may need one version that includes discounts, another that includes tax, another for commissions, and another for accounting reports that excludes tax. If the calculation is built into the table, you have one fixed formula that must try to serve every possible use.
When calculations are in queries, each query can provide the result needed for a particular purpose. An order detail query might calculate the basic extended price. An invoice query might add tax and shipping. A commission query might use a different formula entirely. Reports and forms can use the query that best matches their purpose without changing the underlying table.
Calculated table fields are also not a magic performance feature. They are different from calculating a value once and storing the result in a normal field. A calculated field still derives its value from an expression, and it cannot be indexed like a normal stored field. For ordinary calculations such as quantity times price, calculating the result in a query is usually fast enough.
Sometimes it does make sense to calculate a value and store the result in a normal field. This is a separate design decision often called denormalization. For example, if you have a very large number of completed orders and regularly display monthly sales totals, repeatedly summing all orders for an old month may be inefficient. If prior months are no longer changing, you might calculate the final monthly total once and save it in a normal field or summary table.
That approach is useful when you specifically need to preserve a historical value or improve performance for a heavily used calculation. However, the stored result should generally be an ordinary data field, not a Calculated data type. If you store a calculated value, you must also decide when and how it will be updated when the underlying data changes.
Portability is another consideration. Calculated table fields are specific to Access. If you later move your tables to a database server, build a web application, or work with another developer, the calculated field may need to be recreated as a query, database view, or application-level calculation. Keeping tables focused on stored data and putting calculations in queries can make future changes easier.
Calculated table fields are not inherently bad. They can be reasonable when the calculation is very simple, all required values are in the same record, users should never override the result, and the same calculation is needed almost everywhere the table is used. Quantity multiplied by unit price is a typical example.
Even in that situation, using a query is often the more flexible choice because it leaves room for future changes. A query can calculate the same result without locking the formula into the table design.
The practical recommendation is simple: start with a calculated field in a query unless you have a clear reason to use a calculated table field. Tables should primarily store the raw facts of your database. Queries should turn those facts into useful answers. This keeps your database easier to maintain, easier to expand, and less likely to create problems when business rules become more complicated. Primary Topics calculated fields in Access tables, calculated query fields, table design versus application logic, stored calculated values and denormalization, calculated-field limitations, portability and SQL Server migration, Access troubleshooting, VBA recordsets Secondary Topics self-referencing many-to-many employee relationships, subform filtering behavior, SaveAsText, decompile and compact repair, AI-assisted Access development, Int versus Fix, American versus British number wording, phone numbers and postal codes as text, clo |
