Re: Select * into an external DS, and then adding columns

[Glenn Gundermann <glenn.gundermann@xxxxxxxxx>]

Vern,
The idea is to use a view and not the physical. If the physical is altered, the view isn't broken.
Many people believe this is the best way to go.
Yours truly,
Glenn Gundermannglenn.gundermann@xxxxxxxxx (416) 317-3144-------- Original message --------From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> Date: 2016-02-06  4:24 PM  (GMT-05:00) To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> Subject: Re: Select * into an external DS, and then adding columns 
I am not sure of Dieter's context here - but the recommendation never to 
use a PF in a select statement goes completely against IBM's strong 
recommendation to almost always do that - the optimizer will always go 
back to the PF, anyhow, then find candidate indexes with which to run 
the query. So specifying a PF cuts out some processing time.

Now there can be exceptions - one is using select/omit logicals that 
match the selectivity in a WHERE clause. Things may have changed around 
that landscape with the ability to create sparse indexes now, which are 
like S/O LFs in a way.

Cheers
Vern

On 2/6/2016 1:07 PM, D*B wrote:
> .... as long as the SQLDA to receive the values is compatible with the 
> SQLDA of the ResultSet the values are assigned in the order, they are 
> coming. The (external) DS is resolved to the Format at compiletime, 
> the * from select (*) is expanded at runtime. One recommendation of 
> mine is: don't use a PF in a select statement (never ever), don't 
> change a View (never ever) and you will be happy with select * in all 
> scenarios.
>
> D*B
>
> <Charles>
> That's an interesting point...
>
> Since Alter Table does add columns to the end of the table...
>
> Wonder what would happen if you recreated the table with the new 
> columns in
> the middle.
>
> Charles
> </Charles>