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

This is a relatively large change.  This is something that we may consider in a future update, but the issue primarily comes when using CRUD settings.  You cannot use standard UPDATE or INSERT sprocs if you do this.  You would in essence have to have an UPDATE sproc for every potential combination, which obviously isn't feasible.  Now if you are not using CRUD settings, then this could be done more easily.  In either case, though, this is not an option without using the methods you mentioned.  It is something that we have discussed and may address in teh future, but for now you will have to use the Exclude properties.

I decided to take a look at using the UpdateStoredProcedureName and UpdateUsingStoredProcedure properties. I have created a proc with the required parameters but I couldn't see how I would pass in the paramters at runtime. I checked the forum and help and I'm now left with the impression that this may be a DDT only facility (which we don't use at this stage). If this isn't the case can you point me a description of how to pass paramters to the update proc?

Cheers, Peter

Database Deployment Toolkit -> Stored Procedures -> Table CRUD Stored Procedures

This may not be 100% what you are trying to do, but it does show a sample of an UPDATE stored procecure and what the update sproc will look like (for the most part). 

Yes, I have seen the Help samples. Maybe my question wasn't clear enough:

1) I don't use the DDT.

2) Does using custom update stored procedures require the use of the DDT?

3) If the DDT isn't needed how do I pass my paramenter values to the update stored proc at run time?

Cheers, Peter

On the same topic, what would be the advantage of using SP for the CRUD?

So unless there is special need, having the CRUD without SP would be acceptable for any application?

Just want to be on the safe side, since I do have the DDT, but the tables where designed using xCase with not SP for CRUDs.

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