One of the advantages of the table class is that the object is actually not only the interface but also the data container itself. Hence it does not require an additional object (list and object variable) but only the list variable in the UI.
If we would allow a list that is bound to a table class to get the column definition from the result of the SQL statement then we would combine the advantages of an object variable (making complex select statements in a statement block)…
with the advantages of the table class (having the list variable as the interface object).
I have added an enhancement request (ST/TA/018) to allow this. This enhancement request would allow to have table classes that are not bound to any schema or query class. One could put statement blocks into a method and finally do a $fetch(kfetpchall) to receive the result into the list itself. Up to that point it should already work but the list ought to be defined from the result of the select statement.
