Tables parameters obsolete

Hi all,
In ecc6.0 i have been trying to use tables parameters while designing function modules and it says tables parameters are obsolete, what should be used here and how?
Regards,
C.A

Hi,
Create a table type in Se11 of the type internal table.
Now when you are decalring the internal table in Changing parameter give the reference of that table type.
Create another work area in the source code of function module.
now loop the Internal table sa usual.
regards,
Sujit

Similar Messages

Function moudule error - table parameters obsolete

Subject changed by moderator. Please use a meaningful subject in future
Hi SAP-ABAP experts,
can i get get the information for the following error.
when i was giving *structure* name in tables parameter and gave the 'TYPE' as type in function module screen i was getting the error like this,
TABLES parameters are obsolete.
in 4.7e the function module got activated but in ecc 6.0 i am getting the error like that. can u please clarify the issue
will the type declaration be chaged according to versions of SAP ABAP.
Thanks,
Kavitha.P
Edited by: Matt on Nov 26, 2008 8:09 AM

1. Create a structure in SE11, this will include all the fields you want.
2. Create a Table type in SE11, referring the above structure as the row type.
3. Now, when you use this table type you would need to have a work area to process the data of the table. So, in the program declare a variable with ref to the structure created in Step 1.
Then you can use
LOOP AT T_ITAB INTO WA_ITAB.
ENDLOOP.
where T_ITAB is referring to table type and WA_ITAB is referring to structure.
Thanks
Saurabh

New in NW04s: FL069 TABLES parameters are obsolete (in function modules)

Can somebody explain what is the fundamental reason for this behaviour in NW04s?
In Netweaver 2004s system (like ERP2005 ) you get a warning message in SE37:
FL069 TABLES parameters are obsolete! when defining quite ordinary tables parameter using LIKE and reference to a structure in ddic.
I now speak normal function modules, not RFC enabled.
This example of tables parameter definition will cause the warning message:
return LIKE BAPIRET2
I of course looked the additional help provided by this message FL069. I understood it as following:
you should stop using TABLES parameter and more often use CHANGING parameter by referring a TABLE TYPE defined in dictionary.
if using CHANGING parameter and still want to pass the header line of your internal table you should use a separate parameter (EXPORT or CHANGING parameter)
Developers have too much used TABLES parameters for passing internal tables for reading (by value) rather than to be modified (by reference). As a consequence, fm could have change the header line without caller to know it.
in my opinion the message help is missleadingly telling that header line is no longer passed to function module if TABLES parameter is used. I made a small test program and fm (with TABLES paramerer), and everything worked as before.
The warning message can be ignored by pressing Enter a few times and your fm with TABLES parameter works as it had in older versions of Netweaver.
SAP is still using a lot of TABLES parameters in their own function modules. For example SD_SALES_HEADER_MAINTAIN.
So what is the point of this warning message while everything still works as it used to be and SAP uses this same "OBSOLETE" feature itself? Is there anything more fundamental behind this message? Like TABLES paremeters will no longer work in future versions of ABAP (or header line passing will be ignored in future versions) and therefore developers should switch to CHANGING/EXPORT parameters with TABLE TYPES as soon as possible??
Please understand that I don't need any assistance how to avoid this message, just interested to share your opinions what is the purpose of this warning message.
That is why I did not marked this thread as a question.
Br: Kimmo

Hello,
This is the view under Tables tab in my function builder:
I_T_SELECT     TYPE     SRSC_S_IF_SIMPLE-T_SELECT
I_T_FIELDS     TYPE     SRSC_S_IF_SIMPLE-T_FIELDS
E_T_DATA     LIKE     SFLIGHT (which I change to YBWxxxx)
The moment I change to YBWxxxxx it gives me that error '"TABLES parameters are obsolete! "'
and unfortunately hitting enter several times is not helping either
Thanks!

Tables parameters are obsolete

hi,
      i am trying to create one function module in ecc6.0 version. And after declaration under tables table like "errortable like bapiret2" i am getting the warning "tables parameters are obsolete". please help me to solve this problem.
                                                                    Thanks&Regards,
                                                                     chakradhar.M.

Hi,
It just a warning message..Press enter to continue..
OR
create a table type in the DDIC for the structure and use that table type in the EXPORTING parameter...
Thanks
Naren

Using tables parameters for RFC

Hi All
I am trying to use tables parameter for a Remote Function Call.
It says it is obsolete and not working, we are using ECC6.0 version of SAP.
Any help??

Instead, you should use a table type in a IMPORTING or EXPORTING parameter. Create the table type in SE11 and then reference this table type in your parameter in the IMPORTING/EXPORTING tab. The use of TABLES parameters section is obselete.
Regards,
Rich HEilman

Using a variable not in the Export,Import, table Parameters in USER EXIT

Hi all,
During the Invoice Creation, I need to add an entry in the VBFS table, so that it will be displayed in the system log. In the FM 'RV_INVOICE_CREATE', the structure corresponding to it is XVBFS. There is a user-exit CALL CUSTOMER-FUNCTION '002', in this FM 'RV_INVOICE_CREATE'. But the import, export or Table Parameters does not have XVBFS.
How can I use XVBFS inside the User exit?..
Please help.
Regards,
Asha

Hi,
I dont know whether this will help u...
write this in user exit...to access variables/tables of main program..
FIELD-SYMBOLS: <komv>.
ASSIGN ('(SAPLMEPO)TKOMV[]') TO <komv>.
where.. SAPLMEPO is the main program...and TKOMV[] is a internal table in SAPLMEPO.
regards
Sukriti....

How to declare Dynamic table in Tables Parameters of a Function Module...

Hi Gurus,
I would like to Know how to declare a Dynamic table in Tables parameters of a Function Module.
so that it should be able to hold any table data ....
I have tried all possible ways of trying to assign fields-symbol like declarations which doesnt allow here ...
plz Dont reply with the basics of creating dynamic internal tables, coz my case is not an Internal table it is FM table parameter declaration.....

Hi,
If you are requirement is to create a function module with tables parameter having a generic line type i.e. no specific line type
just declare it with a name under Parameter name with out specifying the type.
A reference function module with such parameter, i would quote is the standard GUI_UPLOAD/ GUI_DOWNLOAD where the parameters specified under TABLES are generic.
If you want to process the values passed to these parameters in the source code of function module, field symbols would be a preferable option.
Regards,
Sharath Panuganti

In BAPI's why the structures are used in table parameters?

Hello sir,
what is BAPI sir? In BAPI's why the structures are used in table parameters? table parameters they are using structures but not using any customized tables ?
regards
rachu.

Hello Rachu
BAPIs provide RFC-enabled interfaces to SAP business objects (e.g. like customer, sales order, purchase order, etc.).
A BAPI does basically the same like you would need to do calling the corresponding transaction (e.g. BAPI_SALESORDER_CREATE -> VA01).
Since they are RFC-enabled they can be called from external systems.
BAPIs represent an external interface for the outside world. Very often you will find within the BAPI that there is a mapping done to the (SAP-)internal structures at the beginning of the coding and vice versa at the end of the coding. Thus, you will (almost) never find any DB table name used as type of a BAPI TABLES parameter.
Regards
Uwe

RFC Lookup Table Parameters Reusability

Dear All
My Requirement is to Map fields in IDoc from the File data ,there are some fields in idoc for which i need to fetch data from SAP.
For this i am using RFC Look up. i am retrieving values from table parameters for RFC.
and this Table parameters are being used muliple times in Mapping.
Right now i have to execute the same RFC for set of input data atleast 5 r 6 times.
This is effective Performance of the Interface
Is there any concept of Reusuability in RFC Lookup while Mapping in PI.?
Can we use Java Initialization section in mapping for executing the RFC once and using the output data in table parameters while mapping various target fields.
Hoping for a Positive Reply
Regards
Bhasker

Hi,
1) If it is PI 7.1 there are mapping enhancements, such as
a) Variables for storing intermediate mapping value,
b) for RFC lookup etc.
you can find the 7.1 pdfs from SDN
2) you can have a two stage mapping, putting them sequentially in Interface mapping object.
First step : Source to Target (orignal target structure)
here you can do all the mapping and also One time RFC lookup, but leaving the other fields where you need the lookup values again
Second step : Target to Target
here already mapped target becomes your input & you know the fields which have the value & the fields that you need to map again and all other fields are one to one mapping.
Regards
Vishnu

Problem with SP with table parameters

Hello, I have problem with stored procedure with paramater which is table type.
I have defined my own type
CREATE OR REPLACE TYPE STRING_LST AS TABLE OF VARCHAR2(80);
and i have stored procedure like this
PROCEDURE probe(outList OUT STRING_LST) IS BEGIN outList := STRING_LST(); outList.EXTEND(); outList(outList.LAST) := 'ONE'; outList.EXTEND(); outList(outList.LAST) := 'TWO'; outList.EXTEND(); outList(outList.LAST) := 'THREE'; END probe;
I have java class which connects to the database and calls this procedure
package mypackage; import java.sql.CallableStatement; import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; import java.sql.Types; import java.sql.Array; public class DAO_Test { public static String toNormalString (String aa) { if (aa != null && aa.startsWith("0x")) { StringBuffer str = new StringBuffer(64); for (int i = 2; i < aa.length(); i += 2) { str.append((char) Integer.parseInt(aa.substring(i, i + 2), 16)); } return str.toString(); } else { return aa; } } public void probe ( ) { try { DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver()); Connection conn = DriverManager.getConnection("dbc:oracle:thin:@server_ip:database_name", "sa", "blahblah"); String sql = "{ CALL PROBE(?) }"; String sqlType = "STRING_LST"; CallableStatement cs = conn.prepareCall(sql); cs.registerOutParameter(1, Types.ARRAY, sqlType); cs.execute(); Array arr = cs.getArray(1); String[] values = (String[]) arr.getArray(); for (int i = 0; i < values.length; i++) { System.out.println("" + i + ": '" + toNormalString(values) + "'");
cs.close();
conn.close();
} catch (SQLException e) {
logger.error("SQLException", e);
} catch (Exception e) {
logger.error("Exception", e);
public static void main (String args[]) throws SQLException {
DAO_Test test = new DAO_Test();
test.probe();
Now...
When I run this class on my local machine the result is OK nad looks like
1: 'ONE'
2: 'TWO'
3: 'THREE'
But when I copy this class on the server and run it, the result is wrong
1: '???'
2: '???'
3: '???'
Here is my environment:
on local machine
eclipse 3.3.1
java 1.5 (java version compiler in eclipse is 1.4)
on server
oracle 9.2.0.6.0
java 1.4.2_08
Result from table parameters are always 3 question marks :|
What is the problem?
Rafał

HI,
I think i found the solution: nls_charset12.jar from page
http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html
I have copied this jar to server lib directory and it works fine :)

Associated table type of the Table parameters in function module

Hi,
If I want to select all the associated table types of the Table parameters used in a given function module in a report, how can that be done ?
Thanks.
Regards,
Rajesh

Try this.
report zrich_0001 .
data: import type table of rsimp with header line,
      change type table of rscha with header line,
      export type table of rsexp with header line,
      tables type table of rstbl with header line,
      except type table of rsexc with header line,
      docume type table of rsfdo with header line,
      source type table of rssource with header line.
parameters: p_func type rs38l-name.
call function 'RPY_FUNCTIONMODULE_READ'
exporting
    functionname             = p_func
tables
    import_parameter         = import
    changing_parameter       = change
    export_parameter         = export
    tables_parameter         = tables
    exception_list           = except
    documentation            = docume
    source                   = source
exceptions
   error_message            = 1
   function_not_found       = 2
   invalid_name             = 3
   others                   = 4.
loop at tables.
write:/ tables-parameter,
          tables-dbstruct,
          tables-types,
          tables-optional,
          tables-typ,
          tables-class,
          tables-ref_class,
          tables-line_of,
          tables-table_of.
endloop.
Regards,
Rich Heilman

Error in FM tables parameters type.

Hi,
I am creating a BAPI FM with the tables parameters with a parameter as
i_ydrseg    type    MMCR_DRSEG.
This is similar to the type as defined in the FM MRM_INVOICE_READ as
T_DRSEG       TYPE     MMCR_TDRSEG.
I have declared the MMCR as types pools in the function group TOP include of the new BAPI. But still i get the error as " Type MMCR_DRSEG is unknown " .
How do i create a table parameter of the type as above ?
Pls help with your ideas.
Thanks,
Stock

Hi again,
1. just to make sure whether MMCR_DRSEG
   is working fine or not,
   and also the type pools is working fine in top include or not.
2. do not use the parameter in import/export/tables parameter.
3. Instead, for testing purpose,
4. declare this in the source code of the FM,
   and check whehter it is giving error not.
regards,
amit m.

RFC Lookup - BAPI-TABLE Parameters problem

Hello All,
I had a scenario where i need to export parameters and am supposed to get import parameters from BAPI between source and target structures.
like -
source --> BAPI execution = result --> target
We had succeeded in getting those but the only problem is with TABLE parameters in that BAPI.
How can we achieve it.
Faster reply would be appreciated.
Thanks & regards
Reddy

Hi VJ,
Its not a simple source-target mapping .
For Ex :
Source-Bapi-Idoc
Source will send some parameters to BAPI and bapi will execute it and respond with values in table parameter of the bapi and result would be assigned to idoc-field.
For this i am using RFC Look up with sample code as :
String rfcxml ="<ns0:Z_BAPI xmlns:ns0=\"urn:sap-com:document:sap:rfc:functions\">" +
"     <A>" + A + "</A>" +       --- Export parameters
"     <B>" + B + "</B>" +       --- Export parameters
//"                       <TABLE><FIELD1>" + FIELD2 + "</FIELD1></TABLE>" +
//"                       <TABLE><FIELD2>" + FIELD2 + "</FIELD2></TABLE>" +
//"                       <TABLE><FIELD3>" + KDMAT+ "</FIELD3></TABLE>" +
//          "<FIELD1>" + FIELD1 + "</FIELD1>" +
"</ns0:Z_BAPI> " ;
Passing A & B as export parameters and getting TABLE-FIELD1&2&3 as response.
I hope some problem in the syntax.
Regards,
HP

RFC Tables Parameters

Hello all
I am having performance issues relating to an RFC call between CRM and ECC. I have been asked to get an RFC call between the two working as quickly as possible.
The code is as optimised as possible, I have replaced onerous FM calls with bespoke code and optimised select statements.
But for some reason I have a niggling thought in the back of my mind that no tables should be passed to the RFC FM in the IMPORTING parameters section and should be passed as TABLES parameters only.
Does anyone know if this is true or not. I have found OSS note 888777 which says that this is true in relation to ABAP-JAVA comms but it doesn't say whether this is the case in ABAP-ABAP.
Any advice/comments most welcome.

Just the once.
The signature of the FM is:
*" IMPORTING
*"     VALUE(I_FIELD1) TYPE ANYFIELD OPTIONAL
*"     VALUE(IT_TAB1) TYPE ANYTABLE
*"     VALUE(I_FIELD2) TYPE ANYFIELD OPTIONAL
*"     VALUE(I_FIELD3) TYPE ANYFIELD OPTIONAL
*"     VALUE(IT_TAB2) TYPE ANYTABLE OPTIONAL
*" EXPORTING
*"     VALUE(EV_RETURN) TYPE BAPIRET2
*" TABLES
*"      IT_TAB3 STRUCTURE ANYTABLE
I'm just wondering whether removing the IT_TAB1 and IT_TAB2 parameters from the IMPORTING section and placing them in the TABLES section would have any performance improvements.

How BAPI Tables parameters are passed by reference

Hi Gurus,
I have a genuine doubt regarding BAPI parameters. I would like to point out the genreal rules of bapi like,
1. BAPI parameters should be passed by value. (Because they are rfc fm's. So both systems will be in different servers. This is the normal scenario.)
2. But the tables parameters in BAPI can't be passed by value. Instead they are passed by reference.
3. I know they use some kind of delta mechanism to transfer tables parameters to remote servers.
So gurus I would like to know what exactly happens when a tables parameter is passed. And also I didn't understand the delta mechanism. Kindly guide me.
Thanks in advance,
Jerry Jerome

You'll see in [SAP Library - RFC - Parameter Handling in Remote Calls|http://help.sap.com/saphelp_nw04s/helpdata/en/22/042551488911d189490000e829fbbd/frameset.htm] that tables are not passed by reference when you use RFC. It also explains the delta.
When you make a remote function call, the system handles parameter transfer differently than it does with local calls.
TABLES parameters
The actual table is transferred, but not the table header. If a table parameter is not specified, an empty table is used in the called function.
The RFC uses a delta managing mechanism to minimize network load during parameter and result passing. Internal ABAP tables can be used as parameters for function module calls. When a function module is called locally, a parameter tables is transferred u201Cby reference". This means that you do not have to create a new local copy. RFC does not support transfer u201Cby referenceu201D. Therefore, the entire table must be transferred back and forth between the RFC client and the RFC server. When the RFC server receives the table entries, it creates a local copy of the internal table. Then only delta information is returned to the RFC client. This information is not returned to the RFC client every time a table operation occurs, however; instead, all collected delta information is passed on at once when the function returns to the client.
The first time a table is passed, it is given an object-ID and registered as a "virtual global table" in the calling system. This registration is kept alive as long as call-backs are possible between calling and called systems. Thus, if multiple call-backs occur, the change-log can be passed back and forth to update the local copy, but the table itself need only be copied once (the first time).

Tables parameters obsolete

Similar Messages

Maybe you are looking for