Open SQL strict mode, SAPSQL_DATA_LOSS and ATC
New features in Open SQL, such as the inline declaration of variables, cause Open SQL to switch to strict mode.
Among other things, this leads to the WHERE condition being strictly checked.
While the following SQL command does not lead to a dump in “normal” mode.
data ls_100 type t100. select single * from t100 into ls_100 where sprsl = 'ES'.
The analog command executes in strict mode leads to a dump SAPSQL_DATA_LOSS (Data was lost while copying a value).
select single * from t100 into @data(ls_100) where sprsl = 'ES'.
The reason for this is that the data of the right part of the WHERE condition could not be copied completely.
In kernel release 745 there was no possibility to check this.
The syntax check In kernel release 753 is able to check too long literals and wanrs with the message: “The type of “‘ES'”. cannot be converted to the type of “SPRSL”. “.
Dynamic too long values, if the right side is a variable that can potentially contain a longer content, will still not be warned.
If you want to perform this check during transport release and prevent release, you can activate the “Syntax Check” for message code “MESSAGEGQC” in the CI/ATC check variant.
This check is a non-remote-enabled check. If a central ATC is used, the code inspector has to be used in every client development system to prevent the release.
In this case, variant TRANSPORT or the alternative variant stored in table SCICHKV_ALTER must be extended by the “Syntax Check”. In addition, the code inspector must be activated in mode ‘E’ in the ATC configuration.
I think I'd keep that one off. There are times when a select single is the quickest way to get to what you want. Does it do anything for the same statement with "up to one row"?
Also because the warnings drive me crazy lately, I've been using pragmas like ##WARN_OK. Would it skip that or would it stop it?
Interesting to learn. I'm glad we are not that strict in our code.
WARN_OK. does not skip the warning and also up to 1 rows also does not affect the warning (I tested it).
It is a matter of the data transfer in the WHERE clause. Open SQL in non-strict mode is more tolerant.
Although it would work, a select
is wrong - technically and from the process point of view, as the internal code for language 'ES' is 'S'.
I like it. But I don't like it. It will keep my code "cleaner", but I may have a lot of warnings that may or may not be needed.
Why not using the new Syntax as it should?
Set the "into @data....." at the end of the select-statement.
the location of the INTO does not change anything, as the WHERE clause is wrong.
Yes, the language is mostly a single character.
That makes sense to me. The next difference would be CDS.. And again written as above it would give an interesting result.
Ask 10 different developers a way to write a piece of code and you could easily get 10 different answers.
Just for fun - I stole this piece of code from a consultant, Jacob Hanncock, the example is from help. Of course I wouldn't use it unless I had already used the internal table for something in my program. I hope this would go through the strict checking.
DATA flight_tab TYPE HASHED TABLE OF spfli
WITH UNIQUE KEY carrid connid.
constants: c_carrid type splfi-carrid value 'LH',
c_connid type splfi-connid value '0400'.
INTO TABLE @flight_tab.
IF line_exists( flight_tab[ carrid = c_carrid
connid = c_connid ] ).