I have a layout that you enter data in. As you enter the layout a script triggers to create a new record. Two buttons on the top "save" and "do not save" have scripts attached to them. "Save" takes you to the main layout and "do not save" deletes the newly created recorded and takes you to the main layout.

 

Is there a better way to handle this?

This layout is a form and the idea is not to see the other records created.

 

Cheers.

In such a scenario, I use a  Temp table with the same fields as the target table, with a Cartesian (X) relationship to the target.  If the user hits the Save button,  a script creates a new main table record, does all the Set Field [] steps, deletes the Temp record, and  goes to the main layout.  The Do Not Save button does the same thing without creating a new record and saving the data.

 

In fact, the same script would work for both cases if you passed which button was pressed as a script parameter.

Is there a better way to handle this?

 

Maybe. You're not telling as what exactly "this" is. If you want users to fill out a "scratch"record first and only then make up their mind about posting it "for real" or abandoning it, then you should [1] give them the opportunity to either commit the record or revert it, and [2] make sure they cannot commit the record other than by using the 'Save' button.

 

Although deleting the "canceled" record would work too, reverting has several advantages, for example keeping the serial number IDs consecutive (provided they are set to generate on Commit).

I use a  Temp table with the same fields as the target table

 

And thus have to maintain two parallel tables instead of just one, plus a relationship and a script, times the number of tables you want to implement such mechanism - all for no good reason that I can see.

Maybe. You're not telling as what exactly "this" is. If you want users to fill out a "scratch"record first and only then make up their mind about posting it "for real" or abandoning it, then you should [1] give them the opportunity to either commit the record or revert it, and [2] make sure they cannot commit the record other than by using the 'Save' button.

 

Although deleting the "canceled" record would work too, reverting has several advantages, for example keeping the serial number IDs consecutive (provided they are set to generate on Commit).

 

Hi comment, thanks for your answers.  Can you describe a better way to approach this?  I have read some recommend creating an identical layout but using global fields to store values and to set those values to corresponding fields after a user clicks a scripted Save Button.  If a user clicks Cancel or Don't Save, then I imagine we would run a script to clear those global fields.

IMHO, using the built-in commit/revert mechanism is much more preferable.