Why isn't the copy of a record a buffercopy but implemented in SmartViewerControl and SmartUpdatableBrowser Cancel The title field is required!

1. Bert Strobbe

   

   19 posts
   Registered:
   25 Oct 2018
   21 Feb 2019

   Link to this post

   We have a question on how the copying of a record is now implemented.
   At the moment the StoreValuesForCopy and RestoreValuesForCopy are used.
   
   As not all fields in the temptable might be linked to a control, not all fields in the temp-table are copied. If we would want to also have the 'non visible' fields to be copied, we would need to do a buffer copy in the correct place (still to identiy where that is), with the possibility to exclude certain fields (for instance audit fields or the record id field).
   
   Is there a reason why the copying of a record isn't implemented this way?
   
   Another reason for this question for the question is that we want to have a single point of code for initialization of a record, no matter if we are creating or copying a record. But we would certainly need to have the copied fields already in place.
   
   
   
   
2. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   21 Feb 2019 in reply to Bert Strobbe

   Link to this post

   The whole update process is built around bound controls and such is the copy. IMHO a copy is the same as an Add and the user re-entering all the same values. You cannot make an user responsible for values he cannot influence. 
   
   But I'm sure you can implement a different behavior around StoreValuesForCopy and RestoreValuesForCopy.
   
   Our recommended approach for additional behavior during Copy however is to user the SmartCopiedFrom field and a Business Entity based implementation.
   
   https://documentation.consultingwerkcloud.com/display/SCL/Knowing+when+a+new+record+is+a+copy+of+another+record+while+saving+the+new+record+on+the+backend