I think its preferential to do it in RowSelecting. It will depend on what you are doing with the results.

If you are changing things like enabled or visibility you may need to create an unbound extension so you can set a flag to be used in RowSelected. This would limit the number of times you are running that query. 

So taking this advice, I moved the queries to RowSelecting and update two unbound decimal fields with a sum of the result.

Then, in the RowSelected event, I am getting the value of the unbound fields and determining if actions should be shown based on the result. However, it doesn’t seem like the values are sticking across to the RowSelected event. It seems like it probably should be, but I’ve not worked with these much in conjuction with each other.

@Shawn Burt - Is this what you were suggesting?

yep :)

Ok, I switched to using e.Cache.GetValue instead of e.Cache.GetValueExt and now it sticks. Thanks!

I have one more issue: there are a few situations where the RowSelected event is called (saving for instance), where my code ran before but now does not. I would like to check if the values gotten in RowSelected are null, indicating that RowSelecting has not run, and then call it, but I can’t find ANY documentation anywhere on how to use this. Maybe that’s because it’s a horrible idea, but I guess I need some additional direction.

I think I resolved this. I moved the selects to a private method that gets called from RowSelecting. That way, in the same situation where I would manually raise RowSelecting, I can just call the private methods. Still executes BQL in RowSelected, but in a much reduced fashion.