Did you check your selection criteria for conversion-exit, you may pass data in external format when it is required in internal format.
Regards,
Raymond
Did you check your selection criteria for conversion-exit, you may pass data in external format when it is required in internal format.
Regards,
Raymond
Hello all,
here is my requirement, hope useful returns will be provided by the experts of topic:
using select in loop is not preferred and not correct in my opinion too.
however when it is used, i know for which record, select is successsful(subrc eq 0) or not successfull.
When 'for all enteries' has been used, is there any way to know for which records select is not successful or successfull?
I need sometimes this info.
thanks in advance.
Hi Dimas,
You Can Check Both Tables after execution of query.
Inside The Loop This Is Only Way To Check Tables Take Data .
It Take Data From reference table Or Not.
I hope You Understand.
Thanks.
Please fill all the selection fields of table in SE16 including conditions(<,<= etc), same as in select query.
Hi,
I am creating a Condition record using the transaction VK11 and when saving a message "Condition record saved" is coming. When i am exiting VK11 or when i am going to VK13 to display the condition record the following message is coming in a popup.
"Express document "Update was terminated" received from author <SY-UNAME>" is coming.
In the popup a button is there "Inbox".
If i am going inside the inbox following log is displayed
System ID: Quality
client: 100
User: SY-UNAME
Transaction: VK11
Update key: some alpha numaric number
Error info: 00 671: ABAP/4 processor DBIF_RSQL_SQL_ERROR
Kindly provide some valuble inputs.
Thanks,
sengodan.
Execute transaction SM13 to find which update FM failed raising the error
(In online documentation Updates in the SAP System (BC-CST-UP), read Analyzing and Correcting Update Errors.)
Regards,
Raymond
I do not think, the runtime creates a pointer to each line of the itab.
The developer creates ONE fieldsymbol ( for a loop for example ) --> a pointer, which is iteratively assigned, pointing to only one line at one time.
With the usage itself it seems to offer a benefit, which isn't really one, If You only read data.
People might say, You can omit a clear, if working with fieldsymbols.
But You have to add a check for sy-subrc, or You will suffer from a dump, which usually never happens, if working with work areas the same way, like fieldsymbols.
The real benefit only comes into play, if You want to modify the data in the internal table, because You are already acting on the line of the table (pointer to record n ), what allows You, to omit any modify to transfer changed values back to the internal table.
In terms of performance I must see it technically and I hope, someone can confirm/reject my statement, so that I (if I was wrong) could keep that in mind.
-----
A fieldsymbol (lets talk about them in technical way, as a pointer) is in fact a variable, which holds an address of another variable( which itself also can hold an address and so on).
Pointers are either 4 byte or 8 byte. So, it does not matter, how much columns Your internal table has, technically the fieldsymbol is either 4 byte big or 8 byte big. And exactly this amount is used in the ram of the application server.
In fact pointers even do not have a type, as usual pointers are always integer.
-----
A workarea is a linear, continous allocation of memory space, exacly matching the data-structure, which is used for declaration. So it is obvious, that this workarea uses much more memory of the ram, as long their elements exceed 4 / 8 bytes.
Still then it is not more performant, because changed data of a workarea has to be transferred to the internal table, (mostly, if one wants to modify), but with field-symbols this step is removed.
So in fact there are two technical reasons for using field-symbols.
One is, You save memory-space and the second is, You save the transferring.
In an even deeper way, one can say, that , by design, a cpu with its address bus is just intended to understand addresses best ( directly after 0 and 1 and hex ).
Hi Dimas,
When you use FOR ALL ENTRIES, the only way to know for which records the data is fetched is you have to loop the records fetched with FOR ALL ENTRIES and read the other table. Then you can find the unmatched records with SY-SUBRC.
And one more thing, using FOR ALL ENTRIES is also not recommended, please check Siegfried Boes' post in following link and try to use JOINS instead.
Will writing an inner join be better or creating a view?
Regards,
Vijay
Hi Avirat,
As you mentioned,
I am not able to run transaction SEGW due to SAP system is not upgraded
once check your Enhancement pack of your SAP system. Because, Gateway Service Builder (transaction "SEGW") is available as of Release 2.0 Support Package 4/5.
For further info, please go through the following link.
The new SAP NetWeaver Gateway Service Builder: Build new OData Services in 3 Quick Steps
Regards,
Vijay
Hi Dimas,
If you are using For ALL ENTERIES then you have to specify all key fields, otherwise it will delete adjacent duplicates .Before using for all entries you have to sort you internal table.
With Regards
Arun VS
Ok that's fine. I dont see any up gradation very soon.
Does any external server can provide access for such transaction?
I don't think so
Hi Khadeer,
Better to use FM 'RH_READ_INFTY_1001' to fetch data from HRP1001.....After getting data into your internal table you can filter your fields using conditions.
Regards,
Arun
I built an ECATT script for transaction /scwm/im_pc (posting change). Now I am trying to replay back the script but I am getting the following error " Screen Check Error: Transaction Code Expected:/SCWM/IM_PC Current:/SCWM/IM_PC,Program". Also I am attaching the screenshot of the error. Do I need to implement any note for this or what needs to be done? Please provide some solution. Thank You!
Hi Experts,
I have a requirement to Make Posting date field non editable in MIGO and ML81N transactions.
For MIGO I found a transaction OMJX, to make the posting date fields non editable. But for ML81N I can't find any transaction.
Please let me know if you know any transaction to make the posting date non editable for ML81N transaction.
Thanks in Advance
Hi Avirat,
Did you find any third party Transaction??
-Vijay
Nope. Cant find anything up till now.
SELECT *
FROM vbap
INTO TABLE gt_ab "gt_ab is like vbap
FOR ALL ENTIRES IN gt_xy
WHERE xxx = gt_xy-xxx.
Assume that when gt_xy-xxx = '001', 500 records will be fetched.
Then if you do this to fill in gt_xy:
DO 500000 TIMES.
gs_xy = '001'.
APPEND gs_xy TO gt_xy.
ENDDO.
It will cause a session restarted because of memory insufficient.
So I think that both SAP server & DB server do not eliminate duplicates in value range,
and for every '001', 500 records will be fetched and appended.
After certain amounts of repeatation, memory is exhausted.
Furthermore, I have tried to calculate the max number allowed of duplicates and found it's
not just max_memory/stucture lenth/hit number, for example, let's assume:
the max memory allowed for one dialog process is 4,000,000,000Bytes
the structure lenth of vbap is 4,000Bytes
hit number for single value is 500
I thought the max duplicate number is 4,000,000,000/4,000 /500, about 2000.
However, when I tried to fill in gt_xy with 2000 times, it will not cause the memory problem.
Acutually, the number of possible duplicates is far more above 2000.
So I guess may the system does the fetch and delete duplicate in the result set at
the same time. Is there anyone also interested in this?
Hi Ming,
the result of a SELECT ... FOR ALL ENTRIES is always DISTINCT (unique) with respect to the fields in the FAE driver table that are used in the WHERE-clause. But in the FAE, this uniqueness is only established after the result is returned from the database. Since data from the database is fetched in packages and not as one big chunk, it would be clever of the database interface on the ABAP side to throw out identical records immediately after each package to not run into memory issues.
Since identical entries in the FAE driver table (that is identical wrt to the selection in the WHERE-clause) are not eliminated before statement execution, it is the task of the developer to care for uniqueness (DELETE ADJACENT DUPLICATES ... COMPARING ...). Otherwise unneccessary database load is generated.
Best Regards, Randolf
As tested, it does go into memory issue when result set is big enough.