Here is the scenario that I need some input on:

A user enters the quantity of widgets that they produced.  They hit the save button.  The production data is stored in table separate from the widget table.  Once the user clicks save, I want the BO to update the On Hand total of the widget in the widget table.  I am thinking that I would place some code in the AfterSave() method to make this happen.  Here's the rub...what if the user entered the wrong quantity (not that this ever happens--I am just doing some just-in-case type of analysis here  ?  The user finds their production data entry and clicks edit, then proceeds to change the quantity and clicks save.  Now, what is the best way of handling this in order to update the widget table with the difference in quantity?

I have some ideas from previous non-SF days, but is there a good SF way to do this?

Thanks,
Bill 

The articles that you read as well as the comments that Peter made are both accurate...up to a point.  The problem is that this is not an exact science and what works well for one query may not work well for another.  This is why I mentioned using the SET STATISTICS command to get a better understanding of what the query is actually trying to do.  WHen we are faced with performance issues we start creating different methods and including them into our queries to see where the best performance lies...and this can, at times, be a length process.  We have some CLR stored procedures that do a lot of the work for us...but they end up calling stored procedures and UDFs to do the heavy lifting.  The problem with a stored procedure is that it cannot be included as part of a query, whereas a view can...but a view generally is a worse performer than sprocs...whereas a UDF CAN be included as part of a query and do a lot of work in the process.  So all of these ideas are right...in the right query   That is why you have to play with your query and learn which will work best for your data in certain scenarios.  I will say, though, that SQL Server is definitely strong enough to handle it and to do it quickly!  We have tweaked queries that when we started were running in minutes and when we were finished had them down to 2 seconds or even less.  So it can be done, but you just have to stick with it....keep it up!

Two days and counting...

My goal is closer.  I am adding a field into my shipments table which will take care of some quantity conversions for me.  That is the most complicated portion of my query, so I thought I would relegate it to the save procedure of the BO.  I'd rather have the intricate calculation done as the row is being saved than on each row during an aggregate query.  With that in place (and it will be done soon...finishing up some testing), the aggregate query speed drops to 1-2 seconds.  That is quite acceptable.

I appreciate everyone's input on this.  I am grateful that there are folks out there who are willing to share their expertise.  And, to provide simple encouragement on a task that is frustrating at times.

Thanks!!
Bill