MTrinder wrote:

Hi Andre

First - can we ask you to open new threads rather than re-opening old ones, it makes life simpler for us

Second - The only way to know how many orders a customer has without querying it from the database is to store the calculated value in the database against the customer - is this what you mean ?

Or do want to perform a "SELECT COUNT(*) FROM ORDERS WHERE CustomerID = x" at the same time the customer entity is retrieved...?

Matt

Hi Matt,

sorry for reopening the thread. What would be the best way when referring to an old topic? Placing a link into the new thread?

I'd like to perform the above query(SELECT COUNT(*) FROM ORDERS WHERE CustomerID = x) while retrieving the customer. It would be possible to add another property for that purpose using a partial class, but I really would like to evaluate that property when fetching the customer to prevent another database access. Plus I don't want to fetch the order entities at all - too much overhead when fetching a thousand customers.

I even thought about implementing a trigger which increases a counter column inside the customer whenever an order is added. But that would be too database specific and I'd like to have a more generic approach.

Regards, André

What would be the best way when referring to an old topic? Placing a link into the new thread? - Exactly that

If you need to fetch many customers at the same time, each with their order total, you should perhaps fetch them as a DynamicList, and then the order quantity can be fetched at the same time as an aggregated field. Is there any reason why you would need to fetch that many entity instances?

Matt

I'm using a stored procedure and a DataReader now. Thanks for the support.

Regards, André