Application Development and Automation 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: 
Read only

Standard RFC for arbitrary table manipulation?

Former Member
0 Likes
1,161

Hello everyone,

we are looking for a standard RFC (coming with R/3 4.6c) empowering a remote application via JCO to alter arbitrary table data. For instance, we retrieve data via RFC_READ_TABLE. The goal is to delete one or the other row of the retrieved data. With RFC_READ_TABLE (as the name already states implicitly) it is not possible to change the backend data.

Any hints or information we might have missed?

From our investigation we can't make out an appropriate RFC. Do we have to implement our own custom RFC/function module to achieve this functionality?

Kind regards

Christian

1 ACCEPTED SOLUTION
Read only

VXLozano
Active Contributor
0 Likes
1,108

First of all, be sure that table you want to alter is NOT an standard one. Are you sure? Really? Pretty sure? Ok, let's continue, then*

I doubt SAP will provide you with a function such you are asking for. It will be dangerous in excess.

But you can make your own RFC. My advice? Do a RFC FOR EACH table to update. Maybe it will be a repetitive work, but will be safer too.

I'm not sure if you can define an "open" table as a TABLE parameter in an RFC (as far as I could test, not possible in 4.6, but I did not make an effort to do it, being honest), but it could be a way to reach your goal.

Anyways, stick with my advice: one function per table.

-


<b>* NEVER use SQL to alter a standard SAP table in any way (UPDATE, DELETE, INSERT). Go for a standard function or class to do it, or a Batch-Input if you cannot find a FM.</b>

5 REPLIES 5
Read only

VXLozano
Active Contributor
0 Likes
1,109

First of all, be sure that table you want to alter is NOT an standard one. Are you sure? Really? Pretty sure? Ok, let's continue, then*

I doubt SAP will provide you with a function such you are asking for. It will be dangerous in excess.

But you can make your own RFC. My advice? Do a RFC FOR EACH table to update. Maybe it will be a repetitive work, but will be safer too.

I'm not sure if you can define an "open" table as a TABLE parameter in an RFC (as far as I could test, not possible in 4.6, but I did not make an effort to do it, being honest), but it could be a way to reach your goal.

Anyways, stick with my advice: one function per table.

-


<b>* NEVER use SQL to alter a standard SAP table in any way (UPDATE, DELETE, INSERT). Go for a standard function or class to do it, or a Batch-Input if you cannot find a FM.</b>

Read only

Former Member
0 Likes
1,108

Hi,

thanks for your information.

What I got so far is that there is and will never be such a standard, generic RFC.

It is a custom table we need to modify, never thought about managing SAP R/3 default table data on table/SQL level.

I am a bit confused about your advice in the end 'NEVER use SQL...'. We are using JCO and are not that much experienced with ABAP programming. Are there function modules providing these kind of functionality (append row, delete row, ...) on top of the SQL-Layer?

So we need to come up with our own functional module, RFC-enabled, to manipulate our custom tables data.

Kind regards

Christian

Read only

VXLozano
Active Contributor
0 Likes
1,108

I'm not really sure if there is a RFC (nor a "normal" function module) that does what you want. I took for sure you did a F4 search in the SE37 transaction and find none.

By the way, I would not use it if I found, except if my knowledge of the full content of the module, the table to be modified and the whole process where that function would be used were perfect. And in that case, I will monitor the program almost twice per minute. Call me paranoid, if you want.

Just go for your own RFC, which you will have absolute control over it, and use all imaginable IF sentences to check you are updating things as they must be done

-

-


About the INSERT thing...

You can use INSERT, UPDATE and DELETE in ABAP. Versus any table which you are authorized by security roles.

BUT

I would NEVER use it in your case (nor in the case of any sentient entity over the whole world) because it will only lead to disaster.

If you are not used to SAP, you must learn a bit more of its structures. I know because I had to do it. SAP doesn't rely on DBMS rules (triggers, foreign keys and so) when it has to manage data. The Data Dictionary is embedded in the application server, to allow SAP to be installed in any database (would be a hell thing to keep track of all different things in all those systems -SQL_Server, Oracle, DB2...- to reach that kind of multi-platform thing). For that reason, you are allowed to delete a header row without having to delete its related positions, causing inconsistences.

If someday someone asks you to do such a thing like a single UPDATE to a standard table, ask him to send you a mail, a printed version of it signed, be sure you have witnesses of the whole process and then, go for it, while looking for a new job where your manager uses his brain.

Message was edited by:

Vicenç Lozano

Read only

Former Member
0 Likes
1,108

I understand your concerns, totally. Off course, it is a big consistency issue.

But if you tell me that using SQL is not appropriate (totally agreed) and that there are no function modules or RFC or whatever on the layer above, I am wondering about the right SAP-way approach. What is the 'right' approach to manipulate backend data? My custom table is just consumed (read) via RFC and should be cleaned up afterwards.

If SQL and FMs are not appropriate, what's the SAP-way policy to manipulate (custom) backend data?

Best,

Christian

Read only

VXLozano
Active Contributor
0 Likes
1,108

Nonono... My lack of English skill makes me hard to be understood.

If your table is a custom one (aka Z-table), you can do anything to it. Just think what would you do with your usual tools (like Visual Basic) and then do it with ABAP. My alerts were all over standard tables.

Just make your own RFC to delete your Z-table and go away happy (and safe)

You can also make a RFC that does the same for any table (check the appropiate SQL sentence syntax -F1-) using "(table_name)", and you will be able to delete anything from anything. But again, you can deliver heavy issues to your client/company if another fresh programmer finds the module and decides to use it to delete a standard SAP table.

-


To delete "any" table, you can use something like:

DATA: any_table_name TYPE string.
DELETE (any_table_name).

In your RFC you can put "any_table_name" as IMPORT parameter and go for it.

But remember, my advice is versus do it. A single RFC for each table