Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Pooled tables are just what they sound like - a table made up of a number of other tables. They do not work in join statements.
If you can determine those transparent tables that make up the pooled table then you can use those to create a join just like another set of transparent tables.
Take a look at the indexes on your pooled table in the technical settings. That may give you a line on which tables are included.
I don't have access to a system at the moment but I seem to remember that over in the FI module the pooled table BSEG had indexes that pointed us in the direction of the individual tables that were included BSIS, BSEK, etc.
I looked at the index option...but for pool tables it seems there arent any indexes..Also BSEG is Cluster Table so probably there are some difference in there base table maintainance...
<i>pooled tables and cluster tables are not created in the database. The data of these tables is stored in the corresponding table pool or table cluster</i>
Arpit - do a select on ATAB with TABNAME = 'T169G'. You'll find the data there but using a concatenated key which you can't use in a join. The data is raw, so you can't read it anyway.
You have to do as Srinivas suggested.
T169G is small. You can read the whole thing in and compare it with T001 which is even smaller.
Well Frnds.... I have another problem because of which I cannot do read on itab... The select statement in my report is dynamic...infact whole report is kind of dynamic... It get generated according to the table and fields you select on screen... so now i want to avoid change in the whole dynamic generation logic...
Also working with SAP for so long...I wonder if SAP doesnt keep track of tables whose fields are used in Pooled table...there must be some place to hold info..
Can you not deviate from your logic and do a conditional code generation depending on whether the table is transparent or pooled? Let us say, you take a table name and fields from your selection screen. Go and find out if the table transparent or not. Then if it is transparent table, do your current JOIN logic code generation and if it is a pooled table, do a slightly different code generation which will define a dynamic internal table of the pooled table and get the entries into it and do whatever your dynamic code should do.
I know it is not as easy as I said it, but may be you can try. But joining them is ruled out for you anyway.
Bluesky
