BDC commit work issue.

[kesavadas_thekkillath]

Hi all,

Im facing a issue in BDC:

In a loop there is a select query called and if sy-subrc = 0 the call transaction using mode N is called in the next step.

first time if the sy-subrc is ne 0 then call transaction is done which updates( considered as new entry )

the table used in the select query.

when the loop executes the second time the sy-subrc is still 4 instead of 0( previous data is not updated in DB ).

So after all the execution only the last record exists in the transaction,

that is the table control index is always 1 due to the select query failure.

Here the problem is when using mode N, when mode A is used its working fine.

The data is not getting updated in db in first loop cycle, so the select query in second loop cycle fails.

The select query gets executed for the same material no's.

I have also tried with explicit commit and synchrounous update is used

Thanks,

Keshav

[ThomasZloch]

Do I understand your last sentence correctly that you already tried option UPDATE 'S' of the CALL TRANSACTION statement? This would be my only idea at this point.

Thomas

[kesavadas_thekkillath]

Hi Thomas,

I have used a synchronous update, but still its not updating.

The message table is also populated with message type success.

Keshav

[vinod_vemuru2]

Hi,

Are you using Synchronous update mode? If not please use this. Instead of only COMMIT use COMMIT WORK AND WAIT and introduce an explicit delay of 1 sec (WAIT UPTO n Seconds) and see(For testing purpose). By the way is the transaction called is Z or standard? Does the called transaction has COMMIT inside?

During debugging, Instead of trying in MODE A, try in Mode N only. Execute for first call in mode N, wait for 2-3 seconds then execute the second select call and see if the first one is updated. If it is updated then explicit delay should solve the issue.

But Why don't you filter out the required records to be updated outside the loop itself by comparing with itab data?

Thanks,

Vinod.

[kesavadas_thekkillath]

Hi Vinod,

Its a synchronous update, i have used commit work and wait.

Its a standard transaction CL20( Obsolete : but the program was coded several years back )

I tried waiting for 10 seconds for each record, only thing is i have to try wait upto statement.

I'll get back to you soon.

Keshav

[kesavadas_thekkillath]

Hi Vinod,

Wait statement doesnt make any difference.

the call transaction is written inside a 'at end of' statement.

Once i hit a F5 at the call transaction statement the control returns to 'AT END OF'.

I tried passing raw comit = 'X' and placed a commit work and wait after the call transaction statement,

but still the control is not coming to the next line after call transaction statement.

Any ideas ?

[vinod_vemuru2]

Hi Keshav,

Can you try the COMMIT from menu during debugging after the CALL TRANSACTION statement?

I tried passing raw comit = 'X' and placed a commit work and wait after the call transaction statement,

but still the control is not coming to the next line after call transaction statement.

You mean control is not coming to the COMMIT statement after the call transaction? Ideally F5 on call transaction should go to the standard code. Was this not happening? If this is not a stupid idea, Try to Regenerate the program Index and activate the main program and see.

Thanks,

Vinod.

[SuhaSaha]

Hello Keshav,

Are you trying to select the same data you have updated via CALL TRANSACTION after the explicit COMMIT WORK ?

I was reading the SAP documentation on COMMIT WORK & something caught my eye

The COMMIT WORK statement closes all database cursors. Open SQL statements that access a database cursor later (SELECT loop and FETCH) lead to an untreatable exception. 

Source: [http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm]

BR,

Suhas

[kesavadas_thekkillath]

Hi Suhas & Vinod,

I'll be back.

@Suhas- Thanks for the info

[vinod_vemuru2]

Hi Suhas,

This applies when we open a cursor for select, use fetch to get the data. Ater the fetch if we commit, then it closes all the open cursors. So next fetch on the previously opened cursor will lead to dump.

Perfect example could be.

SELECT......

Do processing.

COMMIT WORK.

ENDSELECT.

Keshav,

I beleive you are not using SELECT ENDSELECT in your case. If it is SELECT SIGLE/SELECT INTO TABLE, OPEN, FETCH and CLOSE CURSOR operations happens at the back end during the select query execution. ( We can see ST05 trace for this). So as per my understanding COMMIT after the CALL TRANSACTION shouldn't cause any problem.

Please correct if i am wrong any where.

Thanks,

Vinod.

[SuhaSaha]

The phrase "SELECT loop and FETCH" in the documentation says it all.

[vinod_vemuru2]

Hi,

I believe, SELECT LOOP referred here in the documentation is for SELECT ENDSELECT (Which behaves similar to LOOP on itab, record by record processing).

Keshav,

Are you using SELECT ENDSELECT?

Thanks,

Vinod.

[SuhaSaha]

You got me wrong.

I beleive a SELECT loop would be a SELECT ... ENDSELECT block & definitely(i think so) not a LOOP + SELECT combo.

Anyways later on i realised if this were the case our dear friend Keshav would have got an "untreatable exception" which is not the case

Cheers,

Suhas

[kesavadas_thekkillath]

Hi Vinod & Suhas.

Atlast changed the mode to 'E' and everything worked fine.

Thanks for your suport.

Keshav