I have created a cds view. I need to use the backend table but all the fields in SE11 are shown as key fields.
What I noticed is that only if I am using fields that were 'CAST' then this happens, without it only the first two fields are keys.
I was able to solve it by adding
#AbapCatalog.preserveKey: true
and then setting keys manually.
It seems if we use cast or aggregation, SAP by default makes all fields as primary key.
Related
I am creating a logical model on Oracle SQL, however am having a bit of trouble. When I add a relationship between two entities, I'd expect Oracle to add the PK of the parent entity to the child entity, as a foreign key.
But instead of adding the already existing attribute as a FK, Oracle keeps adding an additional attribute with the same name but with a '_1' at the end of the name (e.g. teacher_1 instead of using the already existing 'teacher' attribute)
Any ideas why this is the case?
When using the data modeler, we assume when you add a foreign key, you haven’t already created the ID column.
So we create that for you.
Here’s what that looks like.
I draw the relationship.
You don’t want that.
You want it to use USER.USER_ID instead.
Click on the Column, and toggle it to USER_ID.
When I click ‘Apply’ or ‘OK’ – the generated column goes away.
If you don’t like being asked, you can set the default action when deleting the FK in the preferences: ‘Delete FK columns strategy’
Tip: Draw from Parent to Child
When I go to draw a FK, I always go from child to parent…I think backwards for some reason.
What exactly does the SORT statement without key specification do when run on a standard internal table? As per the documentation:
If no explicit sort key is entered using the addition BY, the internal table itab is sorted by the primary table key. The priority of the sort is based on the order in which the key fields are specified in the table definition. In standard keys, the sort is prioritized according to the order of the key fields in the row type of the table. If the primary table key of a standard table is empty, no sort takes place. If this is known statically, the syntax check produces a warning.
With the primary table key being defined as:
Each internal table has a primary table key that is either a self-defined key or the standard key. For hashed tables, the primary key is a hash key, for sorted tables, the primary key is a sorted key. Both of these table types are key tables for which key access is optimized and the primary key thus has its own administration. The key fields of these tables are write-protected when you access individual rows. Standard tables also have a primary key, but the corresponding access is not optimized, there is no separate key administration, and the key fields are not write-protected.
And for good measure, the standard key is defined as:
Primary table key of an internal table, whose key fields in a structured row type are all table fields with character-like data types and byte-like data types. If the row type contains substructures, these are broken down into elementary components. The standard key for non-structured row types is the entire table row if the row type itself is not a table type. If there are no corresponding table fields, or the row type itself is a table type, the standard key from standard tables is empty or contains no key fields.
All of which mainly just confuses me as I'm not sure if I can really rely on the basic SORT statement to provide a reliable or safe result. Should I really just avoid it in all situations or does it have a purpose if used properly?
By extension, if I want to run a DELETE ADJACENT DUPLICATES FROM itab COMPARING ALL FIELDS, when would it be safe to do so after a simple SORT itab.? Only if I added a key on all fields? Without an explicit key only if I have an internal table with clike and xsequence columns? If I want to execute that DELETE statement, what is the most optimal SORT statement to run on the internal table?
SORT without BY should be avoided in all situations because it "makes the program difficult to understand and possibly unpredictable" (dixit ABAP documentation). I think that if you don't mention BY, there is a warning by a static check in the Code Inspector. You should use SORT itab BY table_line where table_line is a special name ("pseudo-component") meaning "all fields of the line".
Not your question, but you may also define the internal table with primary and secondary keys, so that you don't need to sort explicitly - DELETE ADJACENT DUPLICATES can be used with any of those keys.
Internal tables can have keys that can be inherited from structures the itab is based on or specified. As the documentation says, sort without by sorts by primary key, and that is safe assuming the internal table is implemented correctly.
I think this feature is designed as a dynamic feature to be used with smart table key design. If done correctly, sort without by can get your program to adapt to table key changes in the future. (so if your key changes, sort with change with it). Problems might arise when key is modified in an odd way.
As rule of a thumb:
The more specific your program code is, the less prone to errors (and safer) it is.
So sort by key_id, key_date will always produce the same sort by those 2 fields.
Dynamic components in an application make it more flexible, but tend to have (often hard to notice) bugs coming out when things they rely on are modified .
So if you take the previous example with 2 key fields, you add 1 in the middle (let's say key_is_active between 2 existing fields), sorting results might change in a way you did not expect.
If you had an algorithm that processes based on date, your algorithm might be broken by that change.
In your particular case with delete adjacent I would follow Sandra Rossi's advice.
I'm creating those auxiliary tables, that stores two foreing keys, for a N:N relationship.
I dont want to create another field just for primary key. I want to use both of them as PK.
If a mark both fields as NEEDED and EXCLUSIVE, they'll meet all PK requirements?
No. What you need is to create a unique index holding the two fields, then mark this as the Primary Key.
Other way to solve this problem without using auxiliary table is Lookup fields.
You limit the possible values to a list or a table and those will appear in a dropbox.
And with just a check box in the wizard, you now have a multiple value field.
1) Select your table
2) Select design view mode
3) Select "Lookup Assistance", in the Data Type colunm of the field you want to change.
4) Follow the wizard.
Hint, its better to get the values from a table than from a non-structured list.
It'll ease future changes or the insertion of new values.
I have a table with primary key that consist of two columns and both are foreign keys. I'm creating form on this table and wizard require either sequence or trigger or custom PL/SQL function. I want to get values for both columns from items that will be located on form and filled when redirecting from another page to this page (that I'm creating).
Does function is good solution in this case? How this function should look? Could you write me an example, please? Sample hidden item to be used in form would be P21_ID_ROW_FK.
I will be grateful for any help you can provide.
If you can, I suggest you create a surrogate primary key on your table, and populate it using a sequence or a trigger. Create a unique constraint on your two foreign key columns.
I don't want to start a surrogate vs natural key debate here. Some frameworks, including Apex, just seem to be designed with surrogate keys in mind, the current question being a case in point.
I'm using the shortcut, via properties. When i only need to generate one identifier, i set "(Is) identity" to "Yes", but i can't seem to do it for two rows. Please Help.
no possible with anything that is built in, you will have to roll your own with triggers but with that comes locking and concurrency....don't do it
A table can only have one identity column.
Why do you need two identifiers for one record?
Identifiers in an association table should be foreign keys to the identity values in the related tables, not autogenerated themselves, although you may have a single additional autogenerated identity key in the association table as well.