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 Trent,

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

Peter, I can answer some of your questions:







No, it is completely independent of the DDT. The DDT can automagically create the CRUD sprocs for you, but you can create them yourself. I believe many users are doing it this way.







You don't. The framework does it for you automatically. The help topic indicates how to structure the signatures for each of the types of sprocs, based on concurrency type. If you setup the sproc correclty and setup the BO to use the sprocs (insert, update and delete), then when you call Save or Delete the indicated sproc is automatically called, passing the current values of the current record in the BO.



Note you can use sprocs for none or as many of the CRUD functions as needed. If a sproc isn't used, then the standard SF generated SQL is used instead.



Hope that helps!

Hi Greg, Peter

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

Edhy Rijo

I don't know why Peter is wanting to use sprocs, but here are a couple of common reasons:



1. Security. Often DBAs will disallow any access to tables. All access must be via views and sprocs.



2. Complexity. If you need to do additional processing during a CRUD action, then a sproc is a fast server side option. E.g. a complex trigger needs to be executed when a record is added, complex enough that a normal trigger won't do it.



I'll be interested in other reasons...

Thanks Greg,

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.

Edhy Rijo