I just started learning ABAP and I came acroos some different ways of declaring internal tables but I don't understand the difference between these ways. Which one is the best way?
Sample 1
types: begin of ty_tab,
field1,
field 2,
end of ty_tab.
data x_tab type ty_tab.
data itab like standard table of x_Tab.
Sample 2
types: begin of ty_tab,
field1,
field2,
end of ty_tab.
types x_tab type standard table of ty_tab.
data itab type x_tab.
Sample 3
data t_sflight type sflight.
Sample 1 first declares a type ty_tab with some fields. ty_tab is not a table type, it is a locally defined flat structure type. The data declaration following the type definition defines a local variable with name x_Tab and type ty_tab. The third data declaration then uses the "like" keyword to create a table that has lines "like" the structure x_Tab.
Sample 2 begins again with the definition of a type. But instead of first declaring a structure the data definition defines a standard table of type ty_tab.
Sample 3, as hennes mentioned in his comment, doesn't actually define a table. It defines a local structure based on a structure or table defined in the SAP Data Dictionary, in this case the transparent table "sflight". If you wanted to create an internal standard table based on DDIC table sflight, you would have to change the statement to:
data t_sflight type standard table of sflight.
All three variants are valid. Variant 1 and 2 create the identical (identical as in 'same fields, same properties') internal table with different means. There is no best way, each variant can be used where it fits. If you need a table that looks like one that already exists in the DDIC, use #3. #1 and #2 seem redundant at a glance, but sometimes you may receive a structure as a parameter and now want a internal table with that structure, so you can use the "like" keyword in #1.
Have a look at the SAP Help pages for more information.
Related
I am working on an interface for communicating with SAP RFC functions. I have some questions regarding parameter hierarchy and uniqueness of parameter and table naming to which I can't seem to find an answer anywhere online.
Are the deep hierarchical structures allowed when communicating via RFC? Here are some examples of input parameters:
Example A (Structure within Structure):
Field F1
Field F2
Structure S1
Field S1.F1
Structure S1.S1
Field S1.S1.F1
Field S1.S1.F2
Field S1.F2
Field S1.F3
Example B (Table within Structure):
Field F1
Field F2
Structure S1
Field S1.F1
Table S1.T1
Structure S1.T1.S1 (Row 1)
Field S1.T1.S1.F1
Field S1.T1.S1.F2
Structure S1.T1.S2 (Row 2)
Field S1.T1.S2.F1
Field S1.T1.S2.F2
Field S1.F2
Field S1.F3
Example C (Table within Table):
Field F1
Field F2
Table T1
Structure T1.S1 (Row 1)
Field T1.S1.F1
Table T1.S1.T1
Structure T1.S1.T1.S1 (Row 1)
Field T1.S1.T1.S1.F1
Field T1.S1.T1.S1.F2
Structure T1.S1.T1.S2 (Row 2)
Field T1.S1.T1.S2.F1
Field T1.S1.T1.S2.F2
Structure T1.S2 (Row 2)
Field T1.S2.F1
Table T1.S2.T1
Structure T1.S2.T1.S1 (Row 1)
Field T1.S2.T1.S1.F1
Field T1.S2.T1.S1.F2
Structure T1.S2.T1.S2 (Row 2)
Field T1.S2.T1.S2.F1
Field T1.S2.T1.S2.F2
Are the names of fields, structures and tables per hierarchical level unique? Or are the tables handled separately and could for example have the same name as a field or a structure?
RFC, including parameter types, is described in the documentation of each RFC Interface (documentation in each programming language RFC SDK, or ABAP documentation). You may use RFC both as client and server.
If you use RFC SDK (any programming language except ABAP) to create an RFC server (to expose RFC functions), I guess the types of the parameters support the same types as in ABAP (but I can't be sure so please refer to the documentation of each SDK in case of exceptions).
In ABAP, you can know the types of parameters supported in RFC by combining these two articles:
Properties of Interface Parameters
RFC - Restrictions
If you don't have the time to combine them, here's a summary of parameter types for RFC-enabled function modules:
A parameter can be of any type, elementary (what you call "fields"), structure, table.
Structures can have components of any of the 3 types above.
Tables which are not TABLES parameters can have lines of any of the 3 types above.
Tables which are TABLES parameters must have lines of type flat, which means that the line cannot contain fields of type STRING or XSTRING, nor tables.
The names of fields, structures and tables are unique per hierarchical level, whatever their parameter category, IMPORTING, EXPORTING, CHANGING or TABLES, e.g.
a component of a structure at level 1 may have the same name as a parameter at level 1.
a field and a structure at level 1 cannot have the same name
One exception to the previous rule is that two parameters can have the same name at level 1 if they are of type IMPORTING and EXPORTING (they are considered the same as one CHANGING parameter of that name - see SAP note 357348 - Import and export parameters of the same name).
The rows of one table all have the same type, so your diagrams mentioning S1 and S2 are incorrect, you could just mention S1. Note that a table parameter can have lines also of type elementary and table.
Here is an example of valid parameters of an RFC-enabled function module:
Field F1
Structure S1
Field S1.F1
Structure S1.S1
Field S1.S1.F1
Table T1
Structure T1.S1
Field T1.S1.F1
Table T2
Field T2.F1
Table T3
Table T3.T1
Field T3.T1.F1
Table T1
Table T1.T1
Field T1.T1.F1
Table T2
Structure T2.S1
Field T2.S1.F1
Table T3
Field T3.F1
Reference:
ABAP Documentation
Function Module Interface
Properties of Interface Parameters
FUNCTION, table_parameters (this concerns TABLES parameters with TYPE)
FUNCTION, LIKE, STRUCTURE (this concerns TABLES parameters with LIKE or STRUCTURE)
RFC - Restrictions
Pass-by value must be selected for the IMPORTING, EXPORTING, and CHANGING parameters of a remote-enabled function module. This cannot be specified explicitly for TABLES parameters, but are used implicitly for RFC.
*The formal parameter of a remote-enabled function module must be typed using data types from ABAP Dictionary or using predefined ABAP types. Data types from type groups cannot be specified.
No reference variables can be passed in RFCs. The formal parameters of a remote-enabled function module cannot, therefore, be typed using a reference type.
Others
357348 - Import and export parameters of the same name
I'm working on an Enhancement Implantation on ZXMBCU10 which is called in a custom program couple of levels down the execution path. Inside ZXMBCU10 I want to access the a table in the parent program, which I do in the following method;
Declare the parent program name;
DATA: ex_tbl_name TYPE char100 VALUE '(ZPROGRAM)G_TAB'.
Getting the value through field symbol assignment.
FIELD-SYMBOLS: <fs> TYPE any.
ASSIGN (ex_tbl_name) TO <fs>.
Then I check for successful assignment (which is true).
IF <fs> IS ASSIGNED.
Problem I have is how to read the data in the <fs> field symbol.
I've tried LOOP and READ TABLE, but getting the following;
Both Read Table and Loop is added here just to get the syntax checks
LOOP;
Internal table "<FS>" has no header line - one of the additions "INTO
wa", "ASSIGNING", "REFERENCE INTO", "TRANSPORTING NO FIELDS" required.
required.
READ TABLE;
You cannot use explicit or implicit index operations on tables with
types "HASHED TABLE" or "ANY TABLE". "<FS>" has the type "ANY TABLE".
It is possible that the "TABLE" addition was not specified before
"<FS>".
LOOP AT
The error about LOOP AT (Internal table "<FS>" has no header line - one of the additions "INTO wa", "ASSIGNING", "REFERENCE INTO", "TRANSPORTING NO FIELDS" required), is that you don't indicate the "result" part of LOOP AT i.e. ASSIGNING, REFERENCE INTO... (as said in the message).
For a field symbol, LOOP AT alone is always invalid, and if it's a variable instead of a field symbol it's obsolete because that would imply the use of a header line.
LOOP AT <fs>. " always invalid !
A valid syntax could be as follows: you must declare the field symbol as being an internal table (with at least the word TABLE, or refer to a "Table Type"), any category of internal table is supported for LOOP AT (hashed, sorted, standard), so you can use TYPE ANY TABLE :
DATA: ex_tbl_name TYPE char100 VALUE '(ZPROGRAM)G_TAB'.
FIELD-SYMBOLS: <fs> TYPE ANY TABLE.
ASSIGN (ex_tbl_name) TO <fs>.
LOOP AT <fs> ASSIGNING FIELD-SYMBOL(<line>).
ENDLOOP.
READ TABLE
The error about READ TABLE (You cannot use explicit or implicit index operations on tables with types "HASHED TABLE" or "ANY TABLE". "<FS>" has the type "ANY TABLE". It is possible that the "TABLE" addition was not specified before "<FS>") is that you used READ TABLE ... INDEX ... whose INDEX means that it can only be used with an internal table with category SORTED or STANDARD.
The next code is invalid because of the combination of ANY TABLE and READ TABLE INDEX, because <FS> could eventually be a hashed internal table (who knows), then READ TABLE INDEX would fail, hence the compiler error:
DATA: ex_tbl_name TYPE char100 VALUE '(ZPROGRAM)G_TAB'.
FIELD-SYMBOLS: <fs> TYPE ANY TABLE. " <=== impossible with READ TABLE INDEX !
ASSIGN (ex_tbl_name) TO <fs>.
READ TABLE <fs> ASSIGNING FIELD-SYMBOL(<line>) INDEX 1. " <=== impossible with ANY TABLE !
Solution: to use READ TABLE <fs> INDEX ... you may declare the field-symbol as SORTED, STANDARD, or INDEX (the latter is a generic name corresponding to SORTED and STANDARD).
This code is valid:
DATA: ex_tbl_name TYPE char100 VALUE '(ZPROGRAM)G_TAB'.
FIELD-SYMBOLS: <fs> TYPE INDEX TABLE.
ASSIGN (ex_tbl_name) TO <fs>.
READ TABLE <fs> ASSIGNING FIELD-SYMBOL(<line>) INDEX 1.
Of course, it's assumed that G_TAB is an "index" table, not a hashed table!
PS: in your code you used INTO DATA(lv_fs) but usually if you have a generic internal table ASSIGNING is preferred.
change field symbol type to
any table.
instead of:
any.
I have a Postgres table locations where coordinates are saved in a column geocoord of type :
geocoord_t and the output is "(12.345678,-0.123456)"
Has it isn't particularly useful, I want to change this column to the type point.
With ALTER TABLE maybe, but I don't know how to convert strings to point type.
How can I make that ?
Thanks
PostgreSQL does not have the geocoord_t data type so this is a bit of guesswork, but the general procedure is like this:
ALTER TABLE locations ALTER COLUMN geocoord SET DATA TYPE point;
If there is no automatic conversion from geocoord_t to point then you have to append a USING clause. Seeing that geocoord_t outputs its value in a text format that the point data type can ingest, it could be as easy as:
... SET DATA TYPE point USING geocoord::text
otherwise use a more elaborate expression like:
... SET DATA TYPE point USING point(geocoord.longitude, geocoord.latitude)
or whatever other options the geocoord_t type supports. The second option is probably faster because it avoids conversion from binary to text to binary.
I'm creating a function for querying a SQLite database that should be generic in the sense of reading from multiple pre-defined tables. As part of the function's paremeters, it is necessary to tel which column of the table should be read, an info that is supposed to be passed by an enumerator value. So the call would be something like this:
callMyFunction(enumTableA,enumColumnB);
Since enumColumnB is an enumerator value, the argument is an integer and I would like to identify the column by that integer value without having to use a switch-case for that. Something like this:
SELECT column(enumColumnB) from ...
So instead of passing the name of the column or reading all columns with * and then selecting the desired one when reading, it would use the number of the column as passed by the enumerator value to identify what should be read.
Is it possible to do this for SQLite? I couldn't find any tutorial mentioning such possibility, so I'm almost concluding there is no such possibility (and I'll have to pass the name of the column as argument or use a switch-case at the end), but I'ld like to be sure I don't have this option available.
SQLite has no mechanism for indirect columns.
(SQLite is designed as an embedded database, i.e., to be used together with a 'real' programming language.)
You have to replace the column name in whatever programming language you're using.
I wanna have a table parameter in a RFC function module of type CGPL_TEXT1, which uses the domain type TEXT40, which is a char 40.
I tried to create it:
IT_PARTS_DESCRIPTION LIKE CGPL_TEXT1
But I keep getting this error
tables using like may only reference flat structures
I am also not able to use TYPE. If I do so, I get this error:
Flat types may only be referenced using LIKE for table parameters
Don't go there. For RFC-enabled function modules, always use a structure as a line type for your table. The RFC protocol itself also supports unstructured tables, but many adapters don't. So you should
declare a data dictionary structure Z_MY_PARTS_DATA with a single field DESCRIPTION TYPE CGPL_TEXT2
declare a data dictionary table type Z_MY_PARTS_TABLE using this structure
use that table type in your function module.
Look inside the dictionary for a table type which has only one column representing Your Text.
If You cannot find it, just go the proper way and define a z structure and a z tabletype based on that structure. This is the proper way and I also prefer to use this ( even sometimes, when I would not really need it, i do this ).... because the structures sand table types can be documented.