Re: Nested Table Query

From: The Magnet <art_at_unsu.com>
Date: Tue, 11 Sep 2012 20:39:24 -0700 (PDT)
Message-ID: <943ae54e-bddb-48e9-8010-b40bc4945110_at_l9g2000vbj.googlegroups.com>

On Sep 11, 8:29 pm, ddf <orat..._at_msn.com> wrote:
> On Tuesday, September 11, 2012 9:47:07 AM UTC-6, joel garry wrote:
> > On Sep 11, 8:32 am, ddf <orat..._at_msn.com> wrote:
>
> > > SQL>
>
> > > SQL> insert into hr_info_cpy
>
> > >   2  select * from hr_info;
>
> > > 1 row created.
>
> > Somehow that strikes me as "considered bad practice."  The order of
>
> > columns, like anything else without explicit ordering, is not
>
> > guaranteed.  Try adding columns a and b to the first table, b and a to
>
> > the second, and see if those are selected into the correct place.  Any
>
> > modification of either table could potentially do this.
>
> > jg
>
> > --
>
> > _at_home.com is bogus.
>
> >http://www.crn.com.au/News/315110,oracle-sues-partner-over-theft-clai...
>
> Understood.  The original problem stated the source and destination tables were exactly the same in definition, down to the nested tables.  Thus I took the easy way out.  I do agree that is not the ideal way to solve this problem; I should get cracking and find a more holistic and general solution not based on such assumptions.
>
> I'll take my 50 lashes with the wet noodle gracefully.
>
> David Fitzjarrell

Well, when I defined the tables with their own object types (though the object types were identical in structure) I'd either get an error of 'not enough values' or something related to object ID.

Real strange. Seems like the reusing of the object types, though different STORE AS clauses, somehow told Oracle that it was ok to perform this simple SELECT AS INSERT.........

Oracle = "We can do everything easily, but we make it difficult for you." Received on Tue Sep 11 2012 - 22:39:24 CDT