Rollback In Oracle Forms

You can only use the Clear_form built_in in forms to do a Rollback.
To avoid the messages appearing, you can set the System.Message_Level variable accordingly.

Using rollback and savepoint commands to control transaction in Oracle Forms
should be avoided from the following reasons.

- Savepoints are a crucial part of an Oracle transaction
- And they are especially important for a Forms transaction
- The reason is Forms uses savepoints for it's internal processing
- And the Forms transaction must never be desynchronized with the database
 transaction
To guarantee the consistency of the Forms processing don't try to set a
savepoint of your own. It won't work anyway or it will break your application.
.
Here are some examples:
.
1) If you do this in PL/SQL in Forms:
    SAVE_POINT my_savepoint;
     ...
     ROLLBACK to my_savepoint;
  Forms will not rollback to my_savepoint.
  It will rollback to it's own savepoint.
  This could be the savepoint defined when the starting the app,
  or before starting the commit processing. When calling a new form
  with CALL_FORM a savepoint is set too. This savepoint is not set
  with OPEN_FORM. So a ROLLBACK TO <savepoint> in this case will
  be a rollback of the entire application.
.
2) If you use a ROLLBACK TO <savepoint> in a stored program
   unit, Forms doesn't see this. So you could rollback a part
   of the database transaction without rolling back the
   correlated part of the Forms transaction. Forms transaction
   processing has very closely tied to the database transaction
   processing. So be always very careful in this area.
.
3) The example for ISSUE_SAVEPOINT is in the Forms 6.0 Reference
   Manuel, page 275. It shows an ON-SAVEPOINT trigger used for
   running against a third party database without savepoints or
   with a savepoint processing different from the Oracle
   processing. If Forms runs with an Oracle database it uses
   the default processing, if not is uses a user exit.
.
Here some rules we should follow:
.
- Don't use the SAVEPOINT or ROLLBACK TO <savepoint> commands
  in Forms. You won't achieve what you want.
.
- Don't use SAVEPOINT, ROLLBACK TO <savepoint>, ROLLBACK or
  COMMIT in stored program units. You'll desynchronize Forms
  and the database. There is an exception to this rule
  which will be explained later.
.
- Don't use ISSUE_SAVEPOINT and ISSUE_ROLLBACK other than
  the documented way.
.
Here is the exception to the second rule which might provide
a solution for your problem. If you really need
a ROLLBACK or a COMMIT in a stored program unit, because
you cannot have it in local PL/SQL, do this:
.
- call a new Form with OPEN_FORM(...,SESSION)
- from this form call the stored program unit
.
So you have a different transaction. Everything you do there
doesn't hurt the existing Forms transaction. Just ensure
that you don't use any Forms default transaction processing
in this second transaction.
.
But in most cases you could do the same thing with a second
transaction and Forms default processing. What was designed
to be a rollback to savepoint first, could here be designed
as a full rollback of the second transaction. This is another
rule you always should keep in mind when programming with Forms:
.
Always try to use Forms default processing:
- otherwise you have to do much more coding
- in most cases the default processing is faster than programmed
  solutions.

Schwertner makes some good points, I agree with him.  If you use the "Clear_form" built-in you will get a rollback.  Any other attempt to do a rollback in a form that does not involve clearing the data off the screen is unsupported and is likely to be dangerous and/or difficult to manage.

Can you give us some more details on the kind of  situation where you think it would be helpful (and safe) to be able to do a rollback without clearing the form?

In my application I am inserting & updating  data in multiple tables using INSERT and UPDATE Statements( Here i am not using any Data blocks), so if any exception occurs while inserting or updating then how can I rollback the previous statements if I do not use ROLLBACK.

Using Oracle Forms to do inserts and updates without using blocks based on database tables or views seems like a complex way to get the job done.  Is there a reason you do not want to use the default functionality of Oracle Forms to handle the inserts and updates?

Thanks for the comments made by schwertner and  markgeer.

I would like to explain a scenario in my application which may help in understanding the problem in a better way.

The main functionality of my Application is moving the data (from several tables) of one user to another user.

Let say there are two users "UserA" and "UserB" and now i want to move some(Selected data on the Screen) of UserA  to UserB. So, In such type of situations a data block may not be helpful and one has to uses INSERT statements to move the data to the other user.

So, is there any alternative way?

Thanks for the comments made by schwertner and  markgeer.

I would like to explain a scenario in my application which may help in understanding the problem in a better way.

The main functionality of my Application is moving the data (from several tables) of one user to another user.

Let say there are two users UserA and UserB and now i want to move some(Selected data on the Screen) of UserA  to UserB. So, In such type of situations a data block may not be helpful and one has to uses INSERT statements to move the data to the other user.

So is there any alternative way?

Markgeer made a important, fundamental and correct comment.
Before to dave into technical details you have to read again the Marks' remark and to analyze whether you are using the right tool for your task. Forms primerely is designed for front end GUI interface - entering and modifying of tables data, but it emphsize on the displaying of data on the screen and manipulating it, using GUI objects like buttons, scrollbars, checkboxes, radiobuttons etc. to