Create new record before displaying the detail screen

Create new record before displaying the detail screen

  

Hi,

Currently when a new detail screen is displayed, the record ID is a null value. The "IF" statement causes the record title to show as "New Record" due to the record ID being a null value.

I need a process that leads to having a new record ID created before displaying the detail screen. 

So when the new screen is displayed it will have an established ("created") record ID. No chance for a null value that would cause an "IF" statement to show "New Record".

I need this because I have a process in place where a new record needs to have relational values assigned to it. I currently get an error with new records, but not with records that have been saved.

Hope this makes sense.

Thanks,
Glenn

Solution

In the preparation of the screen just do an If on the ID and do a create there if null. However I try to avoid doing this on screens where possible particularly if you give the user a cancel option as you then need to cleanup the data on cancel or be left with a bunch or "blank" records.

Solution

Hi,

i suggest you can get max id in particular table and add +1 on max id in the preparation.


-Vijay M-


The idea of Vijay as said above is good. But also follow few more steps.

  1.  Create a temporary table(tbl_incr) where you need to store Ids from the main table which will be (max id+1)
  2. When a user clicks on Add New Record, Fetch max id + 1 from the main table and check if it exists in table tbl_incr or not. If not use that id or else again increment it. Do this process until you didn't find that id in tbl_incr. So it will avoid overwriting of max id + 1 in case of multiple users are doing this at the same time.
  3. If a user saves this record, then add the new record in your main table. 
  4. But again, You need to do clean up on a regular basis as John says.

Amol Tupe wrote:

The idea of Vijay as said above is good. But also follow few more steps.

  1.  Create a temporary table(tbl_incr) where you need to store Ids from the main table which will be (max id+1)
  2. When a user clicks on Add New Record, Fetch max id + 1 from the main table and check if it exists in table tbl_incr or not. If not use that id or else again increment it. Do this process until you didn't find that id in tbl_incr. So it will avoid overwriting of max id + 1 in case of multiple users are doing this at the same time.
  3. If a user saves this record, then add the new record in your main table. 
  4. But again, You need to do clean up on a regular basis as John says.

Small note:

When creating the record make sure you set the correct ID.

If two people go to the screen, user 1 will get temp id 1, and user 2 will get temp id 2.

You want to avoid that if user 2 is done earlier that the id of his object will be set to 1 because he finished first.


But since this method requires clean up as well, I think John's idea is better.


Do note that with Jogn's idea, users might see empty objects if there is a list somewhere,

so if you do John's method, make sure you filter the lists for empty records with only an ID.



No, Vijay's idea is not good, it's very bad. Not only because of what Tim explained, but also beause you'll get a database error, as you cannot assign auto-Ids and have it magically working when you peform an UpdateEntity. So it doesn't work. Creating temporary tables is also not good practice, and a lot of overkill (and AOs!).

John's idea works, but has drawbacks as Tim explained, and also you may not have sane defaults for all values.

So to answer the OP: what you want is bad practice. Never ever store partially valid data in the database. You'll regret it for the rest of your life (no kidding). The usual approach is typically the best one: have a single Screen, test the input parameter for NullIdentifier(), refresh after save, etc. If you really don't want to do this, have a separate Screen for the new case, and either redirect to the Edit Screen after saving (with full, not partial data), or go back to the List screen, whatever makes most sense.

Yep Kilian I totally agree. My suggestion is a way to do it if you really have to but not what I would call a good way and if you do do it then you need to delete and do other cleanup

I 100% with the post of Kilian and John

Hi All,

Thank you very much for your suggestions and advise. I now understand and agree that what I am asking to do would cause much more headaches than it is worth.

Unfortunately, my current process is not working as I would like it to.

Attached is an example of what I am currently working with.

In the example the process is:

The Event screen lists events and has a link to create new events in a detail screen.
Within the Event detail screen the event can be edited and participants can be viewed/deleted.
There is a link to Add/Remove Participants.
The Add/Remove Participants screen allows for the selection of a participant and saving them to an event.

The issue is that when a New Event is created it has a null ID for the Event. It is record "0".
New Participants that are added at this time will not be associated with the Event record when it is saved.
The Event Record "0" has leftover participants.

As of now the user has to create an event, save it, then reopen it to add participants.

How can I make it so that participants can be added to a new event and saved accordingly?

Hope that makes sense.

Thanks,

Glenn

Hi Glenn,

The typical solution would either be to not allow adding participants as long as the event isn't saved, or keep the added participants in an in-memory List, and first save the event, then the participants (using the Event Id from the CreateOrUpdateEvent Action) when the user presses save.

Hi Kilian,

Thank you very much for the valuable advise. I expect my user base to be a small group of people (30 to 40) and I plan to set up the Db so that the users will be linked to the records they create. Which leads to my next challenge of relating the user to the records they create and restricting their views to only the records they create. 

I have setup the process to create to record prior to displaying the detail screen. Is working like a charm.

Thanks,
Glenn

Hi Glenn,

Glad to hear it's working now. As for the restrictions you described, I'd add a UserId to the (master) Entity or Entities to be ristricted (if you name it "CreatedBy", Service Studio will automatically make it a UserId), and filter on the currently logged-in user in the Aggregate that queries the Entitiy.

Hi Kilian,

Thanks for the advise. That helps a lot.


Glad I could again be of some help :). As for this topic, if you think any of the answers solved your problem, please mark it as "Solution", thanks.

And then he marks the 'bad' answer as being the solution :-D


Glenn, when you design a solution also look at how outsystems works, if you add a user in outsystems user espace you must first fill in all user data and save before you can add roles, that's the pattern outsystems uses, but the way kilian has described works better out of user experience so I would go that way. Any other way will lead to messed up data or bad way of working. Please mark his solution as the right one, not the working but not really a good idea solution of John :-)