Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

insert + commit work

Former Member
0 Kudos

Hello friends,

There comes a strange problem, I have used the following line of code...

TABLES /CBP/UA03_something.

DATA WA TYPE /CBP/UA03_CALIB.

WA-BNAME = p_user.

WA-WAREA = ls_return-FIELDVAL.

WA-GLTGV = sy-datum.

WA-GLTGB = lv_gltgb.

INSERT INTO /CBP/UA03_something VALUES WA.

if sy-subrc eq 0.

  • "commit work.

endif.

and now when I saw in the table ( /CBP/UA03_something), few records are being inserted ( while testing the code ), however the commit-work is commented, how comes its inserted ????

Now I have to delete the records from that table ?? and delete option is not avaiable in sel6 ?? is there any other way as well?

Thanks

14 REPLIES 14

Former Member
0 Kudos

Hi.

When you use INSERT INTO /CBP/UA03_something VALUES WA.

you don't need to commit work to insert values into the table.

if you want to delete all the records from the abap code use the line

"Delete from /CBP/UA03_something"

don't forget to remove this line afterwards or you'll keep on deleting the records.

Hope this helps.

André

Former Member
0 Kudos

Hi,

records are inserted because of a automatic commit after the run of the program. The deletion of the records can be done via a short abap using

delete from /cbp/ua03_something. " to delete all records or

delete from /cbp/ua03_something

where .... " to delete selective records

regards

Siggi

Message was edited by: Siegfried Szameitat

Former Member
0 Kudos

Dear Haider,

For the first point, the insert works even without a commit work is because an auto commit happens after execution of any program automatically and hence you should remember to rollback in case if you have to.

Point two, the delete option will not be available if you go in display mode of the table or neither in SE16. All that you can do is either delete it in Debugging mode of SE16 or delete it programatically.

Hope this helps....

Regards,

Srikanth

Former Member
0 Kudos

Hi Haider,

Did u check in Debugging mode, or after executing completing the program?

Variant 1

INSERT INTO dbtab VALUES wa.

Inserts one line into a database table.

The line to be inserted is taken from the work area wa and the data read from left to right according to the structure of the table work area dbtab (see TABLES ). Here, the structure of wa is not taken into account. For this reason, the work area wa must be at least as wide (see DATA ) as the table work area dbtab and the alignment of the work area wa must correspond to the alignment of the table work area. Otherwise, a runtime error occurs.

When the command has been executed, the system field SY-DBCNT contains the number of inserted lines (0 or 1).

The return code value is set as follows:

SY-SUBRC = 0 Line was successfully inserted.

SY_SUBRC = 4 Line could not be inserted since a line with the same key already exists.

Bcauz,

<b>Lines specified in the INSERT command are not actually added to the database table until after the next ROLLBACK WORK . Lines added within a transaction remain locked until the transaction has finished. The end of a transaction is either a COMMIT WORK , where all database changes performed within the transaction are made irrevocable, or a ROLLBACK WORK , which cancels all database changes performed within the transaction.</b>

Run your program in one window and after completion check in se16. In your case, an auto-commit is occuring which is storing the records into table.

Regards,

Raj

Message was edited by: Rajasekhar Dinavahi

0 Kudos

hi,

Thanks guys, for your input, meanwhile I have wrote a small program to delete the inserted records, huuuuuuah, thanks, works fine.......

I am surprised, why it did automatically commit ??? well being belongs to java world, I never thought it happend like this, as I was working over the live data, ( It is my mistake that without reading in details what opensql doing used the database trascations commands, ( shot of time and have to finished the things, but now lesson leared, never use assume any thing while coding ....:-) ,

Thanks again for input...

0 Kudos

As the others have said, there is an automatic commit when the program completes. So the easy fix is to change the program:


INSERT INTO /CBP/UA03_something VALUES WA.
if sy-subrc ne 0.
  rollback work.
endif.

and don't comment it out.

Rob

Former Member
0 Kudos

Hi.

1.I believe what happened is that the execution of this program or code section it wasn't within a PERFORM ON COMMIT or in an UPDATE TASK, and that's why it didn't need a commit work to insert the rows, because without the usage of the above mentioned update techniques on the DB, the DB will execute implicits commit works, when you use DB statements.

2.I'm not very familiar with that table you are using but you could try making a program using DB statement 'DELETE' with the same rows you inserted to delete them.

3.There is always another way to do things.

Hope it helps.

Regards,

Gilberto.

Former Member
0 Kudos

Hi Haider,

When you use an Insert on Database table, it directly inserts a record into the table. Commit is not required. Insert statement itself commit's.

Now to delete the records from the table.

1. GOTO SE16.

2. Enter Table name

3. Enter

4. Execute (F8)

5.

a) If you want to delete some particular records, select the corresponding check box and press SHIFT+F2.

b) If you want to delete all contents then:

In the menu bar press TableEntry -> Delete all.

Hope it helps...

Lokesh

Pls. reward appropriate points

Former Member
0 Kudos

Hi Haider,

IMPLICIT COMMIT

-


1. If you read sap documentation / help

on SAP LUW,

we come to know that

whenever screens change,

R/3 does commit automatically.

2. So in our SE38 program,

after the lines are executed,

and the screen for WRITE statement / ALV

comes or the program ends and goes

back to initial screen,

then there is a SCREEN CHANGE.

R/3 does the commit, automatically.

3. This is the reason

UPDATE Module (FM) concept

was developed by SAP

to avoid this Implicit Commit.

Regards,

Amit M.

hymavathi_oruganti
Active Contributor
0 Kudos

using INSERT, MODIFY , UPDATE, DELETE statements

to manipulate database table,

no need to give commit work.

when the program end is reached, automatically the data

will be updated unless any runtime error comes.

if any runtime error comes, the "ROLL BACK" happens automatically.

so no need to commit work statement

0 Kudos

HI, many thanks for so many answers, however all of them says the same story

Just curious, to know in which case "commit work" could be use, or its useless ABAP statement ?

/Regards,

0 Kudos

Hi Haider,

1. Well, we cannot say that its a useless statement.

2. Commit work does :

Calls the subroutines specified by PERFORM ... ON COMMIT

Executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK) specified in these subroutines or started just before

Processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK

Resets the time slice counter to 0.

Ensures that the locks of the SAP locking concept are handled in accordance with its SCOPE Parameter.

Executes a database commit on all database connections

Closes all open database cursors (OPEN CURSOR) on all database connections

Releases all database locks on all database connections

regards,

amit m.

0 Kudos

update bundling techniques are there which use

PERFORM ...... ON COMMIT

CALL FUNCTION ......ON UPDATE TASK

etc.

the above are used if we want to bypass the automatic commits by the system.

0 Kudos

Sometimes, when doing a large number of updates, you may get an error like "the rollback area is too small" and a dump. You can get around this by dividing up the number of updates into manageable chunks and doing explicit commits every so often.

If your question is answered, please close this post and the other ones you have left open.

Rob

Message was edited by: Rob Burbank