Subject Re: [Firebird-Architect] IN LIST
Author Lester Caine
= m. Th = wrote:
> Lester Caine wrote:
>> Jim Starkey wrote:
>>
>>
>>> Language extensions make sense to express something that couldn't
>>> otherwise be expressed or to express something in a form that will
>>> result in better performance. So far, I don't think you've met the test.
>>>
>>>> But just think... This is a case use of well written applications that
>>>> allows the user to filter things based on his need.
>>>>
>>>>
>>> Sorry, I'm not yet convinced.
>>>
>> Me neither.
>> I can't see how you provide the user with the tools to make these random
>> selections in the first place. I end up with a temporary table holding a
>> set of temporary flags to the data in question and check the filters are
>> at least valid. And I then use that as the SELECT for an IN clause. The
>> client app can then modify the contents of the temporary table as they
>> require and simply retry with different selections.
>>
>>
> The problem isn't when you have an interface which allows isolate
> selections *only*. (ie. the user in order to select 100 items must click
> 100 times). This can be also very easily solved as you pointed out, with
> a temporary table of with a Select * from t where id in (1,2,3...); I
> don't see yet the users which can have the patience to click 1500 times
> on different records trying to break down the (official) Fb limit in
> this case.

<Ctrl>C ?
But seriously, building a complex filter with various from and to
elements results in a select with a where clause that will either give a
list of answers or nothing. Adding and removing elements to the filter
changes the 'temporary table' view which is built of a list of elements
in the where clause - I'm not using 'IN' for this - I use the = and
BETWEEN against a selection of available fields. The resulting view of
the data can then be used IN an IN clause to update or delete the
selected set of records.
Of cause if someone wants to write and debug a long list of hand coded
entries ... personally I prefer to get the user interface to work like
the SeaMonkey filter selector - giving available fields and values that
can be added to or removed as required. Think IBOConsole but with an
expandable list for the filter page.

And as Roman says - this needs to be compatible across other databases.

--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php