Hi,

> Not sure I agree - the query obviously has it's uses, as the
> original posted mentioned (he wasn't just being perverse!).
>
> One weakness of Firebird (at the moment) is it's relative
> intolerance of 'silly sql'. Of course, there are always techniques
> to code-around these problems (and if you're experienced with FB you
> will know them), but I think it may discourage new users of FB.
>
> I'm not overly fond of SQL Server 2000, but in years of using it
> I've never experienced an error-free query that didn't work (yeah,
> ok I'm sure there are lots, but *I* havent found any!). On FB I can
> bump into error-free queries that don't work every few days. I can
> always find a work-around, but that's not the point.

It's not like the query doesn't work - it _does_ work, it simply takes
time on largish tables.

> Just like to stress, I'm not critizising FB or the developers here.
> I know everyone's doing their best, and we don't have the resources
> MS have for their products.
>
> I am just suggesting that to be successful in the open source
> database arena, FB should be as tolerent as possible of 'silly sql'.
> Because lots of users won't be experts: they'll be people straight
> from MS Access or MySQL, who wouldn't know transaction isolation if
> it bit their head off.


> > I think another reason why the optimizer doesn't recognize this
> > as a "silly case", is that is was expected that developers would
> > write meaningful SQL :-)

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com