I think you mean record found on a layout. If you create a record for every layout, you have to remember to go back and remove it, before you deploy your solution. Here's a standard snippet of Script found in most starter solutions after Perform Find, or on a FirstWindowOpen:
If [Get(FoundCount) = 0
New Record Request
Thank you for the code. I do indeed mean a "record found on a layout". The purpose of creating the record is to provide the user with only layouts where they can edit information.
There will always be a primary key from the master table stored in a global variable, with the purpose of setting the new record's related keys with the global variable's value. Adding the above snippet after the Perform Find step in the onLayoutLoad scripts looks like a good way to achieve the behavior of always having a record on a layout. I would just a Set Variable steps to get the proper relationship to the Master table.
For this case:
Where a table Y is related to the Master table through another related table X.
In the case of entering a layout whose table is "RelatedTableY" where the Perform Find produces an empty set:
Both global variables($$MasterKey & $$Xkey--which are selected by the user elsewhere via portal) need to have values for this relationship to be true.
What is a good practice if $$MasterKey has a value, by $$Xkey does not?
I could make a dialog pop-up informing the user that they need to select a record from RelatedTableX before they can create a record in RelatedTableY, that then navigates to the layout where the user can select a record from RelatedTableX via portal.
Is this a sound practice? Could it produce an effect that could be unacceptably difficult for the user, that I haven't considered?
I would appreciate some feed back on this process please.
I think you need to describe your basic interface design in more detail. If the user is performing a script to get from the Master Table to a layout for Table Y, the script can refuse to do that and show an error message if $$xKey is empty.
And foreign key fields can be defined to auto-enter the contents of a global variable in order for newly created records to be automatically linked to specific parent records if you are careful to always have valid data in the global variable.
I decided to evaluate that case for the user. User performs script to get from Master Table to a layout for Table Y:
it uses global var to find any selected records,
if that fails, then it uses the Master Key global variable to find any related records at all,
if that fails, it assumes the user wants to enter data and automatically creates a new related record.
I'm trying to keep the number of pop-up dialogs down, and this follows the client's qualitative need.
I like the auto-enter foreign key suggestion, that would save much time compared to writing scripts for each.
In order to auto-enter a global variable value into the foreign key fields of a record on creation, I would set a non-replacing auto-enter calculation's value to the global variable, am I correct? So auto-enter(non-replacing) calc = $$globalForeignKeyValue? I want to make sure so I don't inadvertently destroy my record relationships.
Your calculation expression is simply the name of the variable holding the key value.