Multiple webscreens updating 1 database

Multiple webscreens updating 1 database

i am try to create a small solution for collecting data from a user and saving it into a database.

using a single webscreen is fine (i can do that) ... but .....

i have several webscreens (navigated using next and previous buttons) and a final webscreen to complete the process.
each webscreen gathers a certain amount of data

question - what is the best way of saving the data - on each screen or on the final screen?

if i do it on each screen (the next button calls a save action) how do i cater for the 'previous' button - the data has already been created - do i amend the record or delete it then save a fresh version ... if so, how do i do this?

if i do it on the last screen, how do i pass each screens input data to the final screen for saving (session variables ??? ... if so how??)

i hope this make sense and that some one can tell me what to do
This is how you could do it:
<br />Create a structure that defines the record.
<br />Create a session Variable with the type record.
<br />now at each step of gathering info, update the session record.
<br />at the end of your process update/create the record in your entity using your sessionRecord.

I've added a small solution, how to do it, it's created with Service Studio V5.0.0.64

Hi Paul,


One other valid alternative (which I used several times) is saving the data in temporary records in your database entities. Any "Next" or "Previous" operations in the wizard should save the object in the database (so that the data input by the user is saved between the several screens). The database record is created in the first step of the screen and its identifier is passed between the several wizard screens.


In case your application only accepts records which creation was done executing all the steps in the wizard (i.e. the user did not leave in the middle), you would have to have a field "WizardNotFInished" on your entities that would make it possible to "exclude" the unfinished records from the application logic. Of course, this field is true when the record is created in the first step of the wizard and set to false in the last step.


Comparing this solution with the usage of session variables, I would say that with this one you have three advantages:

- You can easily reuse the wizard screens as edit screens (they receive an ID and edit a database record)

- It is easier to develop and maintain (you can use the Entities and Fields directly in your screens without the need for intermediate structures)

- It is more performant (no need for session variables)


The disadvantage would be the fact that you must deal with incomplete database records in all the business logic of the application (maybe even create a timer that deletes records created in wizards that were never finished).


Best Regards,


Daniel Lourenço