Hello there, I am building a service orders system, and right now when I must add a new service order for  PC repair etc I am using a button that goes to the service order layout and create a new record, the thing is, if I want to cancel that record by whatever means, I have set a button that deletes the just created record and goes back to the main layout. It works ok but it is not safe as if somehow I change layout, if the db loses connection or anything that makes me leave that layout or change records and I press the Cancel button, it will delete a previous record.

 

Is there a safest way to cancel the record adition? Can I somehow use an empty "ghost" record, add the info to it, then if I chose to save that info only then it would create the record?

Thanks again!

The idea is to stop committing the parent record and any of its children until you are ready.  If connection drops before the commit, the records are not created.  Check this video:  Transactions and then search for other discussions on the issue - there are many. 

 

I would approach it this way: under what circumstances can a user cancel a service order? And does cancel=delete or simply set a status to cancel (perhaps requiring a reason?).

There should be no reason that "canceling" affects anything but the current service order record.

The idea is to stop committing the parent record and any of its children until you are ready.  If connection drops before the commit, the records are not created.  Check this video:  Transactions and then search for other discussions on the issue - there are many. 

 

​
Alright I will study that thanks you very much!

 

I would approach it this way: under what circumstances can a user cancel a service order? And does cancel=delete or simply set a status to cancel (perhaps requiring a reason?).

There should be no reason that "canceling" affects anything but the current service order record.

That is actualy a good Idea, I can just set it to canceled status and then I manualy verufy why it was canceled.​

Canceling a 'new record' is same as reverting the record.  If one wishes to cancel a record after a period of time then sure ... check it as deleted or canceled but canceling the creation of a new action is quite normal.  I would suspect that a service order is similar to invoice, i.e. it has the parent invoice record and then a series of lines (known as LineItems).

Once you have committed the parent record, you can no longer revert it or its LineItems.  The only way to protect from connection drop is to hold both the parent record and its lines in a state of 'uncommit' and record-locked so if something happens, it happens to them all as a single entity.  Holding a new record in the middle of its creation in a state of uncommit is also important because multiple commit actions after each edit in a field forces the entire record to be uploaded again to the server.  This back and forth action (traffic chatter) is very wasteful.

Overall, when creating a new record, the user should have the ability to change their mind and 'get out gracefully.'  This means holding the record (and any of its newly created children) in a transactional state of uncommit.  

added:  If you do not have child records on this sales order, I would ask why not?  But if child records are not involved, you can stop commit of a record easily by placing a transparent button or web viewer over the layout and providing a button to SAVE the entry (which would hold single step of Commit Record/Request.  Or the button can ask the User whether to SAVE or CANCEL and if cancel, issue a single Revert.

Edited May 4, 201510 yr by LaRetta

Ah, so it's all about the definition of cancel!

So, imho, you need to separate delete and cancel logic. You might also want to explore creating a Quote that converts to a Sales Order upon client acceptance. Now, you're back to business logic, "when should I allow a Quote to be deleted?"

 

So, imho, you need to separate delete and cancel logic.

​So true.  Pinning down the business logic takes some work for sure.  :-)

During initial data-entry, a User should always be given a safe method to undo or revert new entries at the time of creation.  The only time I've seen this locally overruled is when tight audit is required to account for every invoice number (no exceptions) so VOID is used or an invoice number is assigned at finalization (similar to your suggestion of quote, Barbara.  In either case, a single table is usually all that is required and a Type field can be used to indicate its 'stage' in the process.

There are certainly many variations on the naming and meaning.  To me, CANCEL means ignore what the User was beginning to do.  DELETE is an action to delete a record (or flag it as deleted which may hide it, save it for later deletion after copied to deletion table).  Good discussion!

Morenomdz, I hope this gives you some things to consider.

Yes many ways I can go from now.
 

I was thinking on having a "dummy" table with the exact same fields of the Service order (ID, Client info, Timestamp, Hardware and Problem Description info), have those "ghost fields" on a "New Service Order" layout that doesnt save on modification, then I script up a "Save" button that will set a var for each field and use those to save into a new created record on the main table only when that Save button is used.

Overall I had a web viewer behind it all but it was causing me problems on using it via Web Direct as it stays all over everything on that layout.

You might want to try the old-school approach: use global fields for the user input, and when the user says OK, create the "real" record and write the global fields to their corresponding fields in the service order table.