Hello,

Here's the problem: Let's suppose you have the following generated entity:

OrderDetailEntity:

Qty INT UnitPrice MONEY

Total MONEY

And that you would like to keep the Total field up to date when either Qty or UnitPrice properties are modified so that Total = UnitPrice * Qty. I know that having the Total kept in the database in this case would not be necessary but just consider it as an example.

I have read in the help that you could extend OrderDetailEntity using partial class and for example add a RefreshTotal() method in it, but you would have to remember to call it manually.

An another way that comes to mind is to use the Validation mechanism of LLBLGen Pro to detect when Qty or Unitprice fields are updated... but is it a good idea or is it violating the concept?

My first option would be to not keep this information db. Instead I would make this a read-only calculated property in the entity.

If it must be kept in the db (indexing, quick lookup ...) then I would say there are 3 options 1. use a view to calculate the field. this works across many dbs 2. use an expression field on the table to automatically calculate the total. i know this exists in MS SQL I'm not sure about other dbs 3. use a trigger to update the field in the table and mark the field as read-only in the LLBL entity.

If this were my system I would implement option 2.

Beside the above options, I may add:

• Use EntityValidation (ValidateEntityAfterSave), where you can calculate the total amount and set it just before the save. Check the LLBLGen Pro manual "Using the generated code -> Validation per field or per entity"

jmeckley wrote:

My first option would be to not keep this information db. Instead I would make this a read-only calculated property in the entity.

I would totally agree with you in a simple example like this one... but there are cases where the calculation is much more complex and is based on a set of criterias that could be different from time to time (like Currency exchange rates)... Keeping such calculated values in your database could be interesting, especially if they are extensively used by a reporting/statistics module in your application.

About your idea of using triggers/sp/... and server side calculation, that would do it but the main problem is that they are rarely (if ever) supported by embedded database engines. Another criteria is that I would like the values of calculated fields to be displayed to the user (in some read-only UI controls) before he actually commits his work by pressing the save button.

Walaa wrote:

Use EntityValidation (ValidateEntityAfterSave), where you can calculate the total amount and set it just before the save.

So you would use the validation mechanism too. For now the best I have found is overriding OnValidateFieldValue, because calculated values need to be shown to the user before the entity is actually saved (forgot to mention that in my previous post).

Thanks both of you for your valuable answers.