version 1.0.2005.1 final (self-servicing) VS2005 asp.net 2.0

hiya,

I have to grab a result from a SINGLE database table.

tblOrderItem orderItemId PK orderId quantity

I simply want to: 1) pass the orderId as an argument. 2) return an integer value that represents the quantity of items for a particular order.

ie, I only need to know how many items are in an order, I do not need to group them.

This value will either be zero / greater than zero.

I know that I could use a predicate on an entityCollection, but there must be a more lightweight approach?

What should I use, maybe the “compute” method of a typedList?? I’m looking for the best performing approach..

Many thanks,

yogi

I would use something like this

static int GetNumberOfItemsFromOrderII(int orderID)
{
    // fetch the count
    int numberOfItemsInOrder = (int) new OrderDetailsCollection().GetScalar(OrderDetailsFieldIndex.OrderId, null, AggregateFunction.Count, OrderDetailsFields.OrderId == orderID);

    // return the result
    return numberOfItemsInOrder;
}

cheers David.

I will, surely though it must be a bigger performance hit to use an entityColletion than a typed list?

Also, is it possible to use an sqlDataType to avoid having to covert the result into an object? (it seems unreasonable that I have to create an object variable, simply to handle the fact that the result might be zero, and the getScalar function therefore generates a null)

many thanks,

yogi

getscalar returns a single value, that value could be an int, decmial, float, string, datetime, or db null. the only commonality between these is that they are objects.

it's the developers responsbility to deremine what to do with the result of GetScalar.

yogiberr wrote:

...result might be zero, and the getScalar function therefore generates a null

null and zero are two different values. depending on how this information is used it could represent 2 different scenarios. null meaning no data exists or 0 meaning data exists, but doesn't match your criteria. it's a suddel difference, but some logic requires this.

righto,

Thanks Jason and David for the replies.I had hoped that using an sqlDatatype might have allowed me to avoid having to hadle nulls.Not to worry.

cheers,

yogi