topic package size in Application Development and Automation Discussions

package size

Former Member — Mon, 15 May 2006 07:17:25 GMT

i am using select .... endselect .

i m able to get file also first time but later on i m getting dump , saying somthng abt commit .

thanks in advance .

Re: package size

Former Member — Mon, 15 May 2006 07:19:26 GMT

maybe try the statement " COMMIT WORK."

--Regards

Aswin

Re: package size

Former Member — Mon, 15 May 2006 07:22:28 GMT

chk this out

COMMIT WORK.

Addition:

... AND WAIT

Effect

COMMIT WORK also

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

After the COMMIT WORK has been executed, the event RAISE_TRANSACTION_FINISHED of the class CL_SYSTEM_TRANSACTION_STATE with parameter value CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK is triggered. However, this does not apply to the COMMIT WORK at the end of the update.

The Return Code SY-SUBRC is set to 0.

Notes

All subroutines called with PERFORM ... ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION ... IN UPDATE TASK are also executed in one LUW. When all V1 update requests have been successfully concluded, the V2 update requests (update with start delayed ) are processed, each in one LUW. Parallel to this, the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK are each executed in one LUW per destination.

COMMIT WORK commands processed within CALL DIALOG processing do all of the following:

- A database commit on all database connections (see above),

- Close all open database cursors on all database connections

- Reset the time slice counter

- Call the function modules registered in CALL DIALOG processing using CALL FUNCTION IN BACKGROUND TASK

However, subroutines and function modules called with PERFORM ... ON COMMIT or CALL FUNCTION ... IN UPDATE TASK in CALL DIALOG processing are not executed in the calling transaction until a COMMIT WORK occurs.

Since COMMIT WORK closes all open database cursors, any attempt to continue a SELECT loop after a COMMIT WORKresults in a runtime error. For the same reason, a FETCH after a COMMIT WORK on the now closed cursors also produces a runtime error. You must therefore ensure that any open cursors are no longer used after the COMMIT WORK.

COMMIT WORK may not be used during the update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs that were registered using PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.

With batch input and CALL TRANSACTION ... USING, COMMIT WORK successfully concludes the processing.

Addition

... AND WAIT

Effect

The addition ... AND WAIT makes the program wait for the type V1 update (update with immediate start) to be executed.

The Return Code is set as follows:

SY-SUBRC = 0:

The update was performed successfully.

SY-SUBRC <> 0:

The update was not performed successfully.

Variant 2

COMMIT CONNECTION con.

Effect

The COMMIT command is not executed on the standard database, but only on the secondary database connection specified with con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection as ABAP Source Code.

On the specified secondary database connection, the database commit:

Closes all open database cursors (OPEN CURSOR)

Releases all database locks

Note

Because all open database cursors are closed with the COMMIT, the attempt to continue a SELECT loop after a COMMIT causes a runtime error. For the same reason, a FETCH after the COMMIT to the now closed cursor causes runtime error. You must ensure that open cursors are no longer used after the COMMIT. The only exception are cursors that were opened using the WITH HOLD addition.

Exceptions

Non-Catchable Exceptions

Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT

Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT

Cause: COMMIT WORK is not allowed in the update.

Runtime Error: COMMIT_IN_POSTING

Additional help

Commit Database Changes

plz reward if useful

Re: package size

Former Member — Mon, 15 May 2006 07:34:16 GMT

hii

is the problem coming while debugging ?

one solution could beuse

select into table

and loop through the internal table.

anyway check out the Cause and prerequisites

Chain of causes:

1. There is a statement in one of the Select loops, that leads to a database Commit (or Rollback).

2. A database Commit causes the database to lose the cursor.

3. The system cannot automatically continue within Select loop after loss of cursor.

Following statements lead to a database Commit:

All statements that cause a change of screen (CALL SCREEN, CALL DIALOG, CALL TRANSACTION, SUBMIT, I/W-Message)

BREAK-POINT/ Debugging

. if no debug process free

. always after regeneration (in order to release generation lock).

WAIT Here a work process is released and a Commit is executed.

COMMIT WORK/ROLLBACK WORK

From OSS note 2104 **********************************

Solution

The "COMMITWORK" message appears in the ABAP debugger when programs

orscreensrequireregeneration,or when not enough free capacity

is available inthesystem (or else the debugger blocks a system

process).

Normallyonly one work process is released for debugging. This

isgenerally insufficient ina developmentsystem, as processes

can be blocked for other reasonstoo(background processing,

CPI-C connections,andso on).

The number of work processes made available for debugging can

be configured using the profileparameter

rdisp/wpdbug_max_no

Forexample:

rdisp/wpdbug_max_no = 10

setsthe maximum number of work processes made available for

debuggingto 10. It may be necessary to generally increase the

numberofwork processesatthis time (parameter rdisp/wp_no_dia).

In all other known cases, an error in the application program is

involved.