Video Tutorial: How to create an AfterUpdate event in a form with Microsoft Access. Learn how to select a customer and have all of his address information automatically filled in.
@HalifaxHercules Generally, you are correct. If you can calculate a value in a query, there's usually no reason to store it in a table field. However, there are exceptions. In this video, for example, I wanted to show that you could calculate the value but still give the user the ability to EDIT it, if desired. This way you can say that you're billing the customer for 3 hours at $100/hour, but still manually edit the charge and make it $225 if you want.
@599CD Also, if you have a situation where you have LOTS of records and BIG reports, you might find that your queries and reports will generate faster if you store values that are calculated, but they're not updated often. For example, inventory levels. Yes, you could calculate the quantity on-hand of a product by SUMming up the transaction tables, but it's much faster for the database overall to update that field when products move in or out and store it in the table.
Since ServiceCharge is a calcuated field, I'm wonder why its stored in your database table?
I thought that storing calculated fields or transitive dependencies in a table represents a Third Normal Form violation.
HalifaxHercules 1 year ago
@HalifaxHercules Generally, you are correct. If you can calculate a value in a query, there's usually no reason to store it in a table field. However, there are exceptions. In this video, for example, I wanted to show that you could calculate the value but still give the user the ability to EDIT it, if desired. This way you can say that you're billing the customer for 3 hours at $100/hour, but still manually edit the charge and make it $225 if you want.
599CD 1 year ago
@599CD Also, if you have a situation where you have LOTS of records and BIG reports, you might find that your queries and reports will generate faster if you store values that are calculated, but they're not updated often. For example, inventory levels. Yes, you could calculate the quantity on-hand of a product by SUMming up the transaction tables, but it's much faster for the database overall to update that field when products move in or out and store it in the table.
599CD 1 year ago