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.

Take this small example (I know that you use Delphi):

Build an ERP in which you organize your decision-support objects, let's
say for instance accounts (or product categories, take what you want) in
a tree. As you (probably) know there are very fast virtual trees capable
to handle big amounts of data (personally I use the one from
www.delphi-gems.com - highly recommended). The tree gets its data from
two tables. The one is the ACC table which has the following structure:

ACCID - INTEGER /*PK*/
NAME - VARCHAR(60)
ACCTYPEID - INTEGER /* FK in ACCTYPE */
DB01 - NUMERIC(16,4)
...
DB12 - NUMERIC(16,4)
CR01
...
CR12
<other 100 fields - data & calculated >

The other is the tree:

ACCTYPE
ID - INTEGER /* PK */
CATNAME - VARCHAR(60)
PARENTID - ID
...
< other fields >

We have 50+ users on-line. How can you manage the following case: a
non-deterministic number of users clicks on a non-deterministic
root/high-level check-boxes (which each check-box selects the entire
subtree beneath) on a non-deterministic network (1Gb LAN, 100Mb LAN,
and/or WAN) on a fbserver in a non-deterministic state? (other users may
want exactly in that moment to to the biggest month report for ex.). For
me it was quite hard (read: I didn't succeeded) to keep the server in
sync with the stations in a reasonable amount of time, using temporary
tables. 'Reasonable amount of time' means the amount of time the user(s)
can wait for something to happen. On UI updating processes (selecting,
master-detail, status updating ie. check-boxes, colors etc. ) this
amount of time is very small. M$ has in the Explorer 400ms. IMHO, at
least for me the maximum delay for the average user is somewhere there.
I cannot manage to update/insert several hundreds recs in such a time
under _any_ conditions. Again, I'm speaking about UI updating. The users
can wait much more for a report that for making their selection, for
example. See it for yourself. Of course, you have (at least) an
application in which you use reporting. Take the time from the moment in
which you press the button until your FastReport shows the (completed)
result. Let's say that this is 4 secs (a fast output). After this, take
your main dataset (assuming that you use IBO layer) and write this code
in the BeforeScroll event of the DataSet:
var
t: cardinal;
begin
t := GetTickCount;
t := t+2000; //2 secs - ie. a half from the reporting time. you can
safely try with one sec, a quarter from the reporting time.
while GetTickCount < t do
Application.ProcessMessages; // or, worse, don't do this do only
an empty begin..end
end;

now try to scroll up and down your dataset for a distance of 50-75 recs
only, using the arrows for 10 minutes only. Please tell me your
impressions about the responsiveness of your UI! :)

You see, there are plenty of cases and situations in which this thing
(or something similar) perhaps is good to have it. That's why such lists
is a very good thing. IMHO, a good thing is built in collaboration. For
example, it is natural for you to minimize its importance since you
don't need it, as is natural for me to tend to maximize its importance
since I need it. "To many men, making to many faces making to many
problems... Can you see it? It's a land of confusion" (Genesis) :)

hth,

m.th.