Hi,

I don't use the DDT and let SF's standard CRUD processing do the heavy lifting. So, when I change a column in a row and save the change every column in the BO is included in the update irrespective of if they have been changed or not. What I would prefer is for the Update command to only include in the Update the column(s) that have changed. I know I can achieve what I want by adding entries in the ExcludeFromUpdate list or using my own stored proc to do the update but I was hoping there may be a 'magic property' somewhere that can turn this facility on.

Cheers, Peter

Hi Greg,

Thanks for that - obviously I didn't read the Help file closely enough - back to the books!

Edhey - the reason I was interested in this is that I have a BO that is used in lots of places and, in one form (BO instances), I wanted to turn off concurrency control and only allow the user to update one column (while showing many in the UI). Rather than put lots of column names in the 'exclude from update' list I wanted to use a proc for no other reason is seemed like the easiest thing to do.

In terms of procs rather than using SF's standard CRUD I was very interested in this in the early days of our move to SF because our system supports processing in a factory were response time is critical and we can get transaction rates averaging around on insert a second (with quite a bit of ancillary processing via triggers) while still supporting reporting etc. The existing system, which we are redeveloping, does this well using stored procedures. The CRUD option appeared attractive but I didn't think it would have the performance we were looking for but, after quite a bit of testing, I couldn't see any material difference between the two approaches. I believe the reason for this is that SF parameterises its CRUD SQL code. This makes the database performance quicker (in our case the execution plans remain in cache because they are run so frequently) and it also ensures that text input is treated as text literals and therefore eliminates the problems of SQL injection attacks when an ad-hoc sql statement is generated as string of text and executed.

This is the only time we have ever wanted to move away from SF standard CRUD processing. In terms of Greg's comments re complex processing we have quite a bit of that but we always try and handle that in the database via triggers.

Cheers, Peter 

Also, Edhy, using CRUD is faster than using standard UPDATE commands.  The parger the table, number of columns, and database size, the more significant the performance becomes.  To put it in perspective, we use INSERT and UPDATE sprocs for every single BO in every application that we write (except for the few times that we want to sidestep the standard update logic).  There is really no downside to creating UPDATE and INSERT sprocs...unless you consider performance gains a downside

Thank you guys, much appreciated all the explanations.

Edhy Rijo