One of the nice features of SAP Query is that when you build an infoset for it, you can, in addition to reading data directly from SAP database tables, use plain ABAP code to implement some custom data extraction logic. The only problem with that is security. Normally, SAP Query is used by both developers and end-users, so that many companies allow building queries directly in test or even production systems. But who wants ABAP being written directly in production? On our system you can still build queries based on existing infosets, but changing the infosets is allowed only in our development system. This works well, the only problem is that in the very beginning, changing the infosets was possible in the production system too. And now, before changing an infoset in development, we have to compare its current version against one in the production system. Without having an authorization for SQ02, of course.
As I often do, I looked for alternatives. SQ02 allows you to print a kind of report where the whole infoset, along with selection logic and even manually written ABAP will be shown. And as it often happens, this is done by some ABAP report being called by the transaction, with no additional authority checks in report. Which means, I can get the whole structure of my infoset without SQ02, just by running this report. The report’s name is RSAQSHSG, and all it needs is the infoset name and the output mode, where you can put ‘A’ to see the whole. No tricks, simple and legal.
When I change a database table, adding or deleting fields for example, I always have to use the database utility to have DDL commands like ALTER TABLE executed on the underlying SAP database. This works well in a development environment, but normally it is (and has to be) prohibited for a normal developer in other systems. Things can get even more complex if I am doing tests of, say, a new index in some “other” system and want to drop and recreate an index during my tests. Looks for a help from guys guarding the system? Forget the tests then. But I always remember that many “forbidden” tasks can be done by running some standard report. There is always a great chance that all you need is an authorization for SE38 and the report you use doesn’t do any further checks.
This was exactly the case with the database utility. The screen that comes in SE14 is actually nothing else than a wrapper program that asks you for parameters (what has to be done) and then runs a report to do the job. If you request this to be done in background then of course you can see which program was run and what were the parameters passed. The possible parameter values of this program can be simply learnt by looking at its ABAP code. That was what I’ve done and this saved me some hassles during testing.
The fun is that the program doesn’t do any checks at all – it’s supposed to be run exclusively by SE14. No popup questions to confirm anything. (Hey, are you sure you want to DROP this TADIR?) No matter which system. Can be quite useful if your just-transported database index brings the production system down – you can drop it quickly. If you are lucky to don’t mistype the parameter values.
One of my little ABAP programs surprised me today by crashing into ST22. It was just a simple counter taking values from SY-TABIX in an internal table LOOP. I looked again and again. It seemed that a variable of type INT4 (declared to be compatible with SY-TABIX, as I thought) could not accumulate a five-digit number. The solution was simply to have a fresh look at the underlying data type into Data Dictionary. Here, look at my test program:
lf_tabix type sytabix,
lf_tabix2 type tabix.
lf_tabix = 10000.
write: / lf_tabix.
lf_tabix2 = 10000.
write: / lf_tabix2.
After clicking several times on the type TABIX, I have finally noticed that TABIX is a structure! Four bytes, occupied by one field. And when you use the structure as a whole, ABAP treats it like a character string, and any number greater than 9999 gets screwed.
Well… time to retake BC400.