Hi Patrik,
the display error is a bug and I recommend you open a support incident for that.
The result set data should definitively end up in the correct columns in SAP HANA Studio.
Concerning the "painful" experience of working with super-large tables in the modeler I think it's fair to acknowledge that using such tables in the graphical modeler is kind of the anti-use case.
Using (graphical) models you make your system even more static since you not only define a schema but you build models on top of this schema introducing an additional layer of dependency.
The flexible schema approach is all about not knowing the schema upfront.
Handling such a data store requires coding that can cope with additional and/or missing columns.
Such flexibility on the data storage side comes with a cost on the data consumption side - graphical information models are not made for that.
Another aspect to consider is: the SELECT * approach is typically not what you do with flexible schemas. Instead, think of a flexible table as an option to store multiple data entity types in just one structure.
E.g. when you have a VEHICLES table, you might store BOATS, CARS and SUBMARINES.
For CARS, the miles per gallon (mpg) might be interesting, while for SUBMARINES the max. depth might be crucial.
A query like this could be good for the part of your app that deals with cars.
SELECT VTYPE, MPG, TOPSPEED, BRAND FROM VEHICLES WHERE VTYPE ='CAR';
While such a query would be right for the SUBMARINE module of your app:
SELECT VTYPE, MAXDEPTH, TOPSPEED, BRAND FROM VEHICLES WHERE VTYPE='SUBMARINE';
With the flexible tables we can keep the table structure (in general) and our "car"-code will work, irrespective of any submarine entries.
Of course your application does need to know which columns to access - that's where you basically put the schema definition into your code instead of the database.
- Lars