Edhy,



Just offering some options. You never know when another trick will be needed!



Trent,

I'd agree if it was anything complicated or needed data outside of the current row or in some other table or needed parameters, etc. However, if it's just a simple manipulation of fields in the current row, then I'd lean toward the calculated field. Like I said, I'm using a few of these and they are real easy to deal with, as they just become strongly typed fields in the BO and are always available. Most of the time, things are more complicated and I use the other methods suggested, UDF, sproc, custom BO property...but sometimes...

All good advice, Greg.  I will warn you, though, that the larger your data set becomes, the slower a calculated field becomes...we have just gone through this very thing.  So we are bit more leary of calculated fields (in this manner), especially when dealing with character data, than we once were.  But we will still do this under certain conditions.  If you are expecting this particular table to get very large, then you should probably go with a UDF or sproc, otherwise the calculated field is great.  Also, you can test this against your database and see where you get the best performance.  Use the SET STATISTICS commands to see what query performance difference you get:

That would be the TRUE test on your data.  Also, it can be a really good idea to add some indexes on those fields as well.

Hmmmm...good info Trent. The tables I'm using this on are small and likely to remain small....no wonder I've had no problems. I'll keep this in mind though, going forward. This is thread is another excellent example of why SF rocks

LOL....thanks, Greg!  I always truly appreciate your contributions out here!