Results 1 to 5 of 5

Thread: When Field_Defaults are not defaults

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Mar 2009
    New Zealand

    Question When Field_Defaults are not defaults

    Hi DAW,

    It seems that "Field_Defaults" procedure is only called when;
    Operation_Origin = Self or Allow_Foreign_New_Save_State(self)

    Is there a reason for this? Besides, performance. I can understand if your DD structure is large - setting Field_Defaults for all DDs can be seen as an expensive operation when the default fields are not going to be part of the save operation.

    But on the flip side, because field_defaults are not executed up the DD tree - the 'default' values cannot be used as is.

    For example, using the Order Entry Workspace:

    1. Create a new field in the CUSTOMER table called 'Pays_Tax' as ASC(1)
    2. Set the Customer.dd as per:
      Set Field_Checkbox_Values Field Customer.Pays_Tax To "Y" "N"
      Set Default Value for Customer.Pays_Tax to "Y"
    3. Include dd_debug.pkg, Compile & Run
    4. Load the "Customer Entry" View, Press Ctrl+D for the DD Debugger
      • Notice, the default value for Customer.Pays_Tax in the debugger is "Y" - as per expected.

    5. Load the "Order Entry" view, Press Ctrl+D for the DD Debugger
      • Notice, the default value for Customer.Pays_Tax in the debugger is "N" (not blank but 'N')

    Try explaining this to a newbie.

    Also, with the new addition of Allow Null Parents - an empty/blank/cleared parent record is actually 'valid' but its field defaults can't be used for any field validation as defaults are not set.

    Using the example above, if null customers are allowed in the OrderHea - you might need to code differently if the customer pays tax or not. Because the field defaults for the customer is not set or set incorrectly, orderhea now needs to know the default value of the 'pays_tax' field rather than just doing a get file_field_current_value to determine the default value.

    If the reason is merely 'performance' then IMHO this should be looked at again in the light of the recent additions to the data-dictionary - the above criteria for "field_defaults" goes all the way back to DF3.2 ( I checked ) when computers/hardware weren't that great.

    Last edited by raveens; 7-Feb-2018 at 03:13 PM.
    Raveen Sundram

    Software Development Manager
    Excellent Software Ltd
    Auckland, New Zealand

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts