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.
Related
I've had a constraint imposed on me that my C structure names can't be published via DDS and that I instead have to use a different set of names and then somehow associate the two. It begs the question why not just change my C structure to match the actual DDS names but it is impractical since the names have to be configurable at run time.
Discarding the run-time constraint, I am wondering if there is an IDL keyword that I can use to create an alias between my structures and the desired DDS published names. There is an "alias" keyword but it is for data types.
I did a lot of google searching and had a hard time finding a definition for IDL keywords. The OMG document doesn't provide any insight to indicate this is possible (perhaps it's not).
In DDS, data types are registered with the middleware via a 'register_type()' operation. This operation includes a parameter to specify the 'name' to associate with the registered type. This name is not required to match the name of the IDL type. [If this name is not specified, then the middleware will use the IDL type name.]
Can someone please help me by stating the purpose of providing the json schema file while loading a file to BQtable using bq command. what are the advantages?
Dose this file help to maintain data integrity by avoiding any column swap ?
Regards,
Sreekanth
Specifying a JSON schema--instead of relying on auto-detect--means that you are ensured to get the expected types for each column being loaded. If you have data that looks like this, for example:
1,'foo',true
2,'bar',false
3,'baz',true
Schema auto-detection would infer that the type of the first column is an INTEGER (a.k.a. INT64). Maybe you plan to load more data in the future, though, that looks like this:
3.14,'foo',true
1.59,'bar',false
-2.001,'baz',true
In that case, you probably want the first column to have type FLOAT (a.k.a. FLOAT64) instead. If you provide a schema when you load the first file, you can specify a type of FLOAT for that column explicitly.
Is there a way to create a generic type in Oracle which accepts data from different domains (as numbers and texts)?
OR
Is there a way to create a VARRAY of REF, being the REF a reference to different types of objects.
Something like this:
CREATE OR REPLACE TYPE LIST_REFS AS VARRAY(10) OF REF
Is it possible?
Yes, Oracle has an ANYDATA type which is intended for use as a generic type to hold data of different types. It's a little awkward to use.
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 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.