Stuff SAP could easily fix - rant / wish list

[Jelena_Perfiljeva]

Since SAP still has not opened any Idea-Place-like site for the improvement suggestions, this place seems as good as any to start a wish list / rant combination.

And I'm not even talking about big stuff like why there is no version control for the forms or why there is no billing status for the orders in the delivery-related billing scenario or anything like that. It's the "small potatoes" that I bet would take SAP all but 5 lines of code and some goodwill to make work.

For example, in SE80 I right-click on the report and pick Create -> Transaction from the menu. Even though clearly I'm creating a transaction for a report (did I mention I right-clicked on it?), it's still proposing 'program and screen' transaction type. Oh-kay... But even after I chose the right transaction type why on earth can't SAP fill in the report name here?

Hmm, which program could this transaction be for... How about the one that I've just right-clicked on?! Ugh...

[hardyp180]

Here is one from yesterday.

When creating a data element you can use a domain, or can be lazy and use a predefined type.

I was lazy, and choose predefined type DEC.

The description of DEC is "Counter or amount field with comma and sign"

So you might expect this to allow negative numbers. Sometimes it does, however any sort of dynamic analysis of the data element e.g. POPUP_GET_VALUES will return a structure with the SIGN flag being set to FALSE.

The moral of the story is to always use domains, but it is a still a bug.

[retired_member]

Data elements and domains of the ABAP Dictionary have technical and semantic properties.

While the semantic properties have no impact on ABAP programs, they are evaluated by the classical dynpro framework (as UI5/OData frameworks evaluate CDS annotations).

GUI technologies such as classic dynpros or Web Dynpro are closely integrated with ABAP Dictionary. 

If you look up the Semantic Attributes of Domains, you find:

If a data type of a dynpro field defined in ABAP Dictionary is numeric, the "Sign" attribute must be set so that negative numbers can be displayed on the screen. This attribute can only be specified using a domain.

Not a bug but a well documented feature ...

[hardyp180]

Microsoft also think that if you document a bug really well it ceases to be a bug and becomes a valuable desirable feature.

My favourite IT term is the "principle of least astonishment" which says that in an ideal world the behaviour of software should never shock/surprise you e.g. recently when people got a pop up box saying "do you want to install Windows 10?" and pressed the red X cancel button, they were astonished to learn that instead of cancelling they had said "yes" and the install had begun. Microsoft had to fix that one, though no doubt at the start they would have claimed this was a well documented feature.

If I picked up a box in the supermarket that said "chicken pie" I might reasonably expect that it contained chicken. In the same way if I bought a bottle with green glass that said "extra strong beer" on the front, and found out it actually contained water I would take it back. Possibly the guy in the off licence/liquor store would say "a-ha, if you looked it up on the internet, in our ten thousand pages of documentation you would see that it says that Extra Strong Beer sold in green glass bottles is actually water. So this is better than extra strong beer because this is a well documented feature". Or he might not.

In this case I wanted negative numbers (with sign) so I picked from the list of options the option which had "with sign" in it's name. If a chicken pie with no chicken in it is a bug, why is something that describes itself as having a sign, but does not actually, not a bug?

Or is a chicken pie with no chicken actually a feature? You call it "chicken surprise" and the surprise is there is no chicken.

It is rather like our old friend "for all entries". No one in their right mind would have expected passing in an empty selection table to cause the entire database table to be retrieved. When that happens they are astonished. If I gave you an empty list and said "bring me everything on that list:" you would bring me back nothing as opposed to everything in the world.

Nonetheless SAP refuse to acknowledge this as undesirable behaviour and so document this bizarre behaviour in great detail, magically making it a valuable desirable feature, and now we also have a code inspector check as well.

One possible alternative approach would be to alter the behaviour so that the "for all entries" behaves as any sane person would expect, but in order to fix a problem you have to acknowledge that it IS a problem in the first place, which is not happening here.

Cheersy Cheers

Paul

[retired_member]

One possible alternative approach would be to alter the behaviour so that the "for all entries" behaves as any sane person would expect,

You really propose incompatible changes in a downward compatible release line?

Just to mention it, in NGAP (Release 8.x), where we didn't had to care about downward compatibility too much, the behavior was changed and an empty table leads to an exception ...

[hardyp180]

Do I really propose an "incompatible" change?

Yes I do, and for this reason.

I put it to you, ladies and gentleman of the Jury, that no-one has ever intentionally passed in a blank table to a FOR ALL ENTRIES with the express intention of getting the entire database contents back.

It only ever happens by accident. If you wanted everything from the table you would have no SELECT criteria at all.

Moreover I am sure as sure can be that there are hundreds, if not thousands of "customer" programs out there with FOR ALL ENTRIES tables with no checks, that every so often get a blank table passed in and the TIME OUT or give wildly unexpected results. I found one in our system this very day that had been sitting there for ten years, a time bomb waiting to go off. I added in a check, just because it had never happened, did not mean it might not happen next week as it was feasible that a blank selection table could occur in some rare circumstances.

If you did introduce such an incompatible change in behaviour, for wildly illogical to logical, then suddenly a load of holes would be fixed overnight.

If you think about it when would you deliberately take advantage of the bug in FOR ALL ENTRIES and use it to bring back the whole table? SELECT-OPTIONS do the job far better.

I would imagine the whole idea of making things downwardly compatible would be to avoid the situation where something that works fine suddenly starts working differently.

Surely it is a different kettle of fish to fix something that has NEVER worked properly?

As an example, when I worked in Country X (named changed to protect the innocent) in the  legacy system there was not room for the totals of the report to be at the bottom where they logically should be.

So in the old system they were printed on the side of the report, at right angles to the rest of the report. You had to print out the report and rotate it 90 degrees to read the totals.

So when I rewrote the same report in SAP I proudly said you can now have the totals at the bottom, each total underneath the column of figures it was totalling.

The powers that be thought about it, and then asked if could I make SAP print the totals at right angles along the side, just like the old report, as that is what people were used to?

i.e. they wanted a downward compatible change to replicate something that did not work in their old system and so was worked around. They were very upset when I told them it could not be done in SAP.

How about a check box in all new programs with "make FOR ALL ENTRIES work properly" which is on by default for all new programs? Rather like what happened when "fixed point arithmetic" was introduced? Probably technically impossible for some reason or another, but would have been a nice compromise.

Cheersy Cheers

Paul

[retired_member]

To answer shortly:

• You don't imagine how many fixes of  known ABAP bugs/pecularities and how many ABAP renewal attempts were already hindered by the downward compatible trap.
• The checkbox would rather be a "clean ABAP" Checkbox and entail a little bit more than "FOR ALL ENTRIES works properly" (in fact I'd expect no FOR ALL ENTRIES at all any more). I am proposing that since long. But who am I? Only the documentation writer. Where are all the architects, customers, really demanding that? But I don't give up. Meanwhile, we have the technical possibility for ABAP versions for other purposes and maybe I will live to see a reuse of that concept for a "clean" ABAP version.

[Former Member]

As far as I care,  FOR ALL ENTRIES emulates select options,  so it's not a bug when an empty table is passed and you get the whole world back.  You are placing NO restrictions on your select.  Simple enough to understand.

Rich

[matt]

Can you update the documentation for FOR ALL ENTRIES so it says "Don't use this unless you really really have to. Use a JOIN instead. It's usually better".?

[retired_member]

Thin ice.

Joins circumvent table buffering. FOR ALL ENTRIES in most cases not.

We'll declare FOR ALL ENTRIES as obsolete in the moment, we have that Problem solved.

[Former Member]

Richard Harper wrote:

As far as I care,  FOR ALL ENTRIES emulates select options,  so it's not a bug when an empty table is passed and you get the whole world back.  You are placing NO restrictions on your select.  Simple enough to understand.

Richard,

Your logic does make sense.

However, when FOR ALL ENTRIES table is empty, the whole where statement is being ignored and not only the FOR ALL ENTRIES-relevant criteria.

[matt]

Joins circumvent table buffering

I use HANA. What do I care?

But FAE does have its uses and I'm not sure it can be entirely made obsolete. For example, in BI transformations, there are routines where we are supplied with a data package in an internal table. Often we have to enrich this data from db tables. FAE is perfect for that.

[Jelena_Perfiljeva]

Where are all the architects, customers, really demanding that?

They are right here, on SCN. What other channels do ABAPers have?

I've checked all the "customer engagement" etc. stuff - there is no ABAP track anywhere. As an SAP employee, you should have access to the private SAP Mentor Jam space (otherwise email Jason Cao to hook you up). In that space I created a discussion not so long ago on how can we get a function added in SAP because it seemed desirable to many customers (myself included). All I got was crickets.

I do agree with Paul that no one (except for Richard Harper apparently ) expects to pass an empty FAE table and get something as a result. And no, it's not like selection options where you specify the restrictive selection criteria, so if no criteria is entered it is quite logical that all data is selected (= I do not care to restrict my query, just give me everything). "For all entries" should mean 0 result for 0 entries. I wouldn't mind that changed retroactively everywhere. Somehow when my authorization stops working after a support pack it's "we fixed the glitch" and no one cares if it technically "broke" my access.

The reality though is that the business does not really care and SAP doesn't make any more money from ABAP, so this thread is as far as it will go, I suspect.

[raghug]

Shai Sinai wrote:

Richard,
Your logic does make sense.
However, when FOR ALL ENTRIES table is empty, the whole where statement is being ignored and not only the FOR ALL ENTRIES-relevant criteria.

Please don't change it, I like wondering why my program is suddenly slow and the sy-subrc didn't work after a FOR ALL ENTRIES with an empty table. Keeps me on my toes, and gives me another novelty to show off to ABAP newbies.

[hardyp180]

Two element have come in the "for all entries" which I would like to address.

In regard to FAE being like a select-option I would say there is both a semantic and a technical difference.

Semantically speaking a SELECT-OPTION is used in the initial database SELECT and if you were to phrase the request in the from of a sentence it would come out "I would like all the records in this table filtered by the following restrictions". If there were no restrictions (all select options blank) you would logically expect the entire table to come back.

With a FAE you are doing a subsequent read. You may have got a big list of sales orders, looped through the list and got a selection table full of material numbers. semantically you then say "for all of these materials, give me the material name". If there was no list of materials, bringing back any result at all would be unexpected behaviour.

Technically a FAE is more like a PARAMETER than a SELECT-OPTION. In the above example a FAE is rather like

LOOP AT material_table INTO material_structure.

  SELECT matnr makt

     FROM makt

     APPENDING CORRESPONDING FIELDS OF material_name_table

     WHERE matnr = material-structure-matnr

      AND      spras = sy-langu.

ENDLOOP.

When a parameter is blank, you would expect no record to be returned. If the table in the above example was empty you would expect the SELECT not to be called at all. as I mentioned before this is all about what you would logically expect as opposed to bizarre behaviour which astonishes you.

The next point is all about how databases work. About ten years ago I read in the SAP Press book with an Egg on the front about improving the quality of ABAP development, a highly technical explanation about how you should not do a JOIN on transaction data and maser data. In their example there were a large number of sales order items, 75% of which had the same material.

They talked about how in such a case the database would have to do far more work than it should have to do, accessing the name of the same material again and again. So they recommended doing a JOIN on VBAK/VBAP, getting a filtered list of unique materials, and then doing an FAE. They said this would lower the overall run-time.

I did a test (ST05) at the time, and the results in my system bore this out. Naturally, if the master data table was also buffered, as Horst alluded to, then it would be virtually mandatory not to have the buffered table in the JOIN, which is why you get a code inspector warning.

The caveat here is thus - I did my test two database versions ago. In the interim ten years have databases got cleverer and thus the original problem with joining transaction and master data has gone away? the guy who sits next to me says they are bound to have, but I just don't know. If someone does know, please tell me.

Lastly, Horst says I just cannot imagine how frustrating it is to go to the powers that be and say 'something is broken, can I fix it" and being told that fixing it is against the rules, it has to stay broken forever. In actual fact in one place I worked I found myself in that situation on a regular basis.

I honestly do not think the original intent of the "everything must be downward compatible" rule at SAP was to ensure that once broken, something stayed broken for all time. That is just an unfortunate side affect of blind adherence to a rule, obeying the wording of the rule strictly and not thinking about the original purpose of the rule.

UK singer Fred Wedlock said it best:-

"Jobsworth, Jobsworth, it's more than me job's worth. I don't care, rain or snow, whatever you want, the answer's no"

Cheersy Cheers

Paul

[matt]

It didn't used to be mandatory to have super->constructor( ) in constructors. It is now. Just sayin'... 

How hard is it to scan all uses of FOR ALL ENTRIES and see if there is any code that doesn't check for empty driver table, and that really is the desired functionality?

[SuhaSaha]

Matthew Billingham wrote: 

How hard is it to scan all uses of FOR ALL ENTRIES and see if there is any code that doesn't check for empty driver table, and that really is the desired functionality?

My 2 cents ...

You can define a "custom" code inspector variant which checks the following:

1. Can FAE be replace by better performing JOIN?
2. Are the relevant checks for empty driver table in FAE implemented?

The standard CI check variant 'DEFAULT' doesn't include these checks.

BR,

Suhas

PS: I am working on an ABAP740 SP12 system

[Peter_Inotai]

For super->constructor( ) at least there was a warning ().

From other hand a new statement or option would make more sense, instead of making FOR ALL ENTRIES working in a new way. Anyway JOIN is better most of the case, but there are some cases when it's not.