Skip to main content

I have a view with 3 fields that can be automatically filled (default proc) when selecting one value from a view having all three values concatenated.This makes finding things a lot easier for the user. The field is only defined in the view and nothing is stored in the database….

A similar situation now exists in a table. There is currently no need for a view instead of this table, so an expression field could be the solution here. Expression fields in the SF however are by definition read-only. 

So why not have the developer deside whether an expression field is read-only or not; most of us are wise enough to know what we're doing.

To show what I mean, see link below… I made an expression field editable using SQL on the SF database, and you;ll see what I want to achieve. Works fine according to me.

https://mcmurdock.stackstorage.com/s/4pGhtJXw03Y9EH8

 

 

We have a quite a few tables and table variants with a collection of expression fields which we'd have to convert into views to make these fields editable. It would indeed be handy to be able to use expression fields in a handler and update the relevant records upon an update of the expression field in the form.