--- In ib-support@yahoogroups.com, "Alexander V.Nevsky" <ded@h...> wrote:

> --- In ib-support@yahoogroups.com, "Marco Menardi" <mmenaz@l...>
> wrote:
> > --- In ib-support@yahoogroups.com, "Martijn Tonies" <m.tonies@u...>
> wrote:
> > > Hi Marco,
> > >
> > > > Hi, I can't test FB RC2, so, since there is no mention in
> "What's new"
> > > > document, does anyone here know if this syntax is now correct
> (and
> > > > works ;))?
> > > > insert into PhoneList(client_id)
> > > > select client_id from Clients order by birthday
> > >
> > > Why the ORDER BY?
> > >
> >
> > For instance, I have triggers that prevent inserting people jounger
> > than the older in the table, or force code to be longer thant the
> > previous entered, and so on. When I need to "copy" the data from one
> > table to the other without "order by" I will not know the order in
> > which the records are extracted and then inserted, so trigger
> > generated exception can be risen.
>
> Marco, though I see in your arguments only intention to use ordering
> instead filtering, what IMHO generally is not good practice, I can say
> you in FB1.5 you can use order by within insert from select and within
> subselects with First 1. I was one of those who supported this feature
> when it was discussed, but personally I see it's usage with First only
> - non-relational filtering technique included into SQL server toolkit
> requires further extensions of old technique to be usefully used, no
> more.
>
> Best regards, Alexander.

Ordering instead of filtering? I can't see how filtering can make
sense in the "insert from..." problem I have.
Thing about that table that requires, forced by integers, that records
are entered by the user in a certain order. It works ok. But if you
have to automatically "pump up" (already correct and fine) data in
that table with "insert from...", you can't do it in the correct
order, so trigger protection fires.
I don't understand why you cite "First 1"... I don't need to use
"First n", just to pass ALL THE DATA in the correct order.
In addition, you learn that a "select" can have the "order by". Having
things work or not in different context meas that simple problems can
become nightmares when you have to solve them in a different context
(i.e. a subselect, a where clause, a insert from, etc.). This really
ha slown down my developement time a lot, since you make the
assumption that a certain design is good, only to find later that has
some drawbacks because you can't take advantage of it in certain
queries because of SQL imp0lementation limitations.
I do love and support Firebird, but I just want to point out that
things shluld work the same everywhere it's reasonable they do.
thanks a lot :)
Marco Menardi