Delete a column from an internal table

[Former Member]

Hi,

I have a program that involves a SELECT from several tables in SAP which are in the same step joined with a dynamic JOIN statement I have built based on info from DD-table DD05P. The program thus joins the tables, SELECTs the required fields from them and fills them into a dynamically generated internal table that has exactly these fields with the right datatype, length etc. All that is very flexible according to what the user wants.

My current scenario involves tables KNA1, T001, VBRK and VBRP. All well and good, only VBRK and VBRP cannot be joined directly according to DD05P, only indirectly via a third_table, VBUK.

So I programmed an exception: When VBRK is there and VBRP is there, but VBUK is not, I add it automatically so the code will run.

The remaining issue is: I need this table - one field from it is quite enough - until the very end, that is, up to that SELECT command. The user then gets that internal table with all the fields he selected - including the one field I added automatically from table VBUK.

This last field, however, is not of interest to the user, I just added it so it will all work. Thus, I would like to delete that column from the internal table after the SELECT, before processing it further.

Is there any way to do that that is less troublesome than truncating the fieldlist, generating a new table with one field less, then looping through the first internal table and filling the (all but one) fields into the second?

Thanks a lot!

Best regards,

Sapperdapper

[Former Member]

?? of course VBRK and VBRP can be "joined directly".  Not sure where you are going with this?  Are you trying to report by bill-to partner or something?  If so, did you read SAP Note 185530 on how to do this efficiently?  One should never attempt reporting SD/LE without reading and understanding this essential note first.

VBRK and VBRP have one very important common field....like most transaction tables...in this case it is VBELN or the "billing document number".  If you don't need the data from a table, look at ST05 or SE30 Tips and Tricks button, selecting data from more than one table, and check out the very efficient and useful "subquery" technique....but if you don't need the VBUK column, don't go after it....it is NOT necessary for joining VBRK and VBRP....

As SAP Note 185530 says, I would be starting with the following to obtain invoices for a particular customer.

SELECT FROM vrkpa WHERE kunde = ...    SELECT FROM vbrk WHERE vbeln = vrkpa-vbeln

[Former Member]

Hi David,

yes, VBRK and VBRP can be joined directly, I'm aware of this and I've done so for m.o.l. the last four years.

The focus of my current program is different, however: I am joining the tables dynamically and I draw the information on how to do this from a dictionary-table, DD05P. In that table (on my system, which is quite old), there is no direct relation recorded, neither from VBRK to VBRP nor the other way round, but merely from VBRK to VBUK and from VBRP to VBUK.

In a dynamic approach, I can only use the information I find in the SAP tables and in DD05P, that is what I find, so I can use only this. That is how I come across the table VBUK.

Is it different in updated systems? Can you find a direct relation between those two in DD05P there? I'm really curious to know - we have been badgering our boss for an updated system for a while now, but that would cost us good money, so... well, maybe the angels will bring us one for Christmas 😉

Best regards,

Sapperdapper

[Former Member]

I see....  SAP designed those tables using the VBUK VBELN field as the foreign key, but one might understand, I guess, since VBUK would be one table for which there would be an entry for every document, once it was created and saved... I don't like that design!

Maybe one could look at, say, table DD03K, obtain the key fields list for VBRK, then read DD03K for VBRP and search for at match on the two that way, or read DD03 by a join on the tabnames and reatain the common fields that are not MANDT or CLIENT?  There's a table of the secondary indices fields, too, but I don't remember the DD* name, at the moment.

At any rate, that DD05* set of tables doesn't appear to be useful for what you need to do....

[Former Member]

Hi David,

I will have a look at table DD03K, I didn't know that one up to now. Same story for DD03. I found DD05P by using the SQL_trace, it was the first I hit upon and it seemed to do the job, but that doesn't mean it's necessarily the best choice.

From what you say, I'd guess the approach using DD03 would be slightly problematic since the fields to be used to link two tables don't always have the same name. In SAP, the same field (name-wise) in different tables might mean sth. different and different fields (name-wise) might mean the same... I'll look at it anyway.

Right now, I will go with what I have: I need to have something to show quite soon, an approach that works, though maybe not ideal. But I will look at those and see whether they help me make the program better and more reliable.

Best regards,

Sapperdapper

P.S.: Coming back to my original question - do you have an idea how to do that?

I don't have the function REVERSE, so cutting the last field from my FieldList will be one challenge, then I'd have to use the same method I used originally (from a class) to build a second table and transfer the fields one-by-one from one wa to the other.

Is there no faster way to achieve that?

True, giving the user one field more that he might not need at all is no big issue, but it would just be nicer.

[Former Member]

Hi,

okay. I take it there is no easier way to do that. Then I guess I'll either do it the established way or I'll just leave it. One superfluous field is no big issue, there are other points in the overall program suite where the user can delete that, and if it's properly named, the user can easily recognize it and he needn't use it.

I guess that third-table game can't be helped since SAP sees VBRK and VBRP no different from VBUK, so from SAP's point of view, the tables are all directly related. The fact that the user might need info from the former two, but not from the latter is of course not known to the program. That's something I'll have to cope with.

I'll close this thread then.

Best regards,

Sapperdapper