2016 Apr 15 9:37 AM
Hello!
i am creating bdocs and send them to CRM. To select the Data, i was trying to use the CURSOR-Statement. Well i figured out, that curser gets reseted in the process and so i cant use it.
Now im looking for a dynamic possibility to select data from tables similar to the cursor.
is there a fm i can give a tablename and blocksize so it is returning me small blocks of data each call? (without using intern cursor statement ). the data tables can also be very large ( > 20 mio entries) so FMs like RFC_READ_TABLE have too bad performance.
If there is no FM / Method like this. how to do a dynamic select, with dynamic table and where clause so i can get small blocks of any table, sending them and then selecting the next block. Like saving the last row's key fields and putting them into the where clause of next select in loop. so i get only the new values.
can you help me out with this?
I hoping there are some FMs... because im looking for an easy solution
regards
Stefan Seeburger
2016 Apr 15 10:34 AM
All you describe sounds like: Use a cursor.
Well, so I want take another view on the problem. Have you already analyzed why the cursor is reseted? Maybe you can avoid the reset and your cursor approach works well.
2016 Apr 15 11:18 AM
Hello Armin,
unfortunately BDOCs are sent via FM CRS_SEND_TO_SERVER. this somehow resets the cursor.
the logic is to select a block of rows, and call CRS_SEND_TO_SERVER for this block of data. then select the next data.
if i dont do it block-wise i get in conflict with big tables, because of the size limitation of programms and itabs
regards
Stefan Seeburger
2016 Apr 15 11:37 AM
Have you specified WITH HOLD at your OPEN CURSOR statement?
There is an interesting note in the ABAP language help:
The addition WITH HOLD is ignored by implicit database commits, by commits produced by the statement COMMIT WORK, or by any rollbacks that always close the database cursor.
2016 Apr 15 11:44 AM
yes i tried with "WITH HOLD" but as described in the docu, it gets closed by commit work (if i get it right, only if you use FM DB_COMMIT instead of "commit work" this would have an effect. but as i have to use FM CRS_SEND_TO_SERVER i have no chance to change this.
regards
Stefan Seeburger
2016 Apr 15 12:22 PM
Is it possible to call the FM in an own task (SAP-LUW)? Maybe you have to wrap arround a RFC-FM.
2016 Apr 15 2:29 PM
Hi,
it is not possible to warp an RFC-FM around it, because the FM CRS_SEND_TO_SERVER can not be called in update task. (also calling with destination 'NONE' did also reset the cursor.)
the FM CRS_SEND_TO_SERVER itself got a parameter UPDATE_TASK, but this has no effect on the resetting of cursor.
somehow i guess i need something else than cursor, thats why im asking for a dynamic select.
i guess im not the only 1 wanting to use cursor with commits inside the processing.
i was hoping there is a FM to select data from any table somehow using key fields (generic) and internal storage of last selected row (generic) to remember where to select new entries.
so i get a new pack of data each time i call this fm. because large tables can not be processed at once.
LG
Stefan Seeburger
2016 Apr 18 9:35 AM
Hello!
does any 1 know if there is a FM like this?
regards
Stefan Seeburger
2016 Apr 18 2:26 PM
I'm not familiar with your exact scenario, but looking at a where-used-list for CRS_SEND_TO_SERVER I found (among many others) function module CRS_TEXT_EXTRAKT.
This seems to circumvent the issue by selecting portions from STXH with option ORDER BY PRIMARY KEY and a WHERE-clause composed from the last key values of the previously processed portion. Maybe you can deploy something similar for your particular task.
Not sure though how this compares in terms of runtime to a OPEN CURSOR / FETCH construct.
Thomas
2016 Apr 18 4:28 PM
Hi all,
i found a solution - Regarding my other post:
i also had the feeling background-processing could help, but wasnt able to call the FM this way. now its working.
sadly i found nothing to do a dynamic select. but its fine for me since dynamic select was only plan B.
thanks for your help anyway.
regards
Stefan Seeburger