Geoff Worboys <geoff@...> wrote:

><snip lots of stuff that does make sense and goes a long way
>to explaining how we got to this spot - given that I missed
>lots of the earlier posts, thanks>
>
>...
>> I'm using a IBOQuery for the Select SP as:
>> SELECT * from MYSP(:K) where f_substr(UPPER(<word/phrase to check in string>),
>Upper_Item) >> -1
>...
>
>Anything that is specified in the select statement happens at
>the server, so you never get to see anything about the
>(potentially) thousands of things that the server is doing.
>
>In your above example all the client gets to see are the
>results coming out of MYSP that passed the WHERE clause.
>
>I guessing that what Helen probably had in mind with the
>fetch_count idea is that you would call MYSP from the client
>without any where clause - so you actually get to see the
>details of every row. You would then do some sort of filter
>or tag process to identify the matching rows - at the client.
>
>It is also possible that Helen may have thought you could do
>something like this...
>
>CREATE PROCEDURE GETALL_ML (
> K INTEGER, -- the decryption key
> W VARCHAR(128) -- the word you are searching for
>) RETURNS (
> MLID INTEGER, -- the matched record id (or 0)
> REC_COUNT INTEGER, -- the total possible records
> FETCH_COUNT INTEGER -- the number have processed
>)
>AS
> DECLARE TMPID INTEGER;
> DECLARE MLUPITEM VARCHAR(128);
>begin
> select Count(ml.ml_id) from Masterlibrary ml INTO Rec_Count;
> Fetch_Count = 0;
>
> for select m.ml_id, MyUDF(m.ml_upper_item, :K)
> from MasterLibrary m
> Order by 3
> INTO :TMPID, :MLUPITEM
> do begin
> Fetch_COUNT = Fetch_COUNT + 1;
> if (f_substr(UPPER(W), MLUPITEM) > -1) THEN
> MLID = TMPID;
> ELSE
> MLID = NULL; -- mark it as not matched
> suspend;
> end
>end
>
>
>Now when you call this procedure you get a return row for every
>row that is searched, whether it matched or not. You can tell
>if the row was a match by whether MLID was null or not.
>
>Because you get rows returned for each search you will actually
>get fetching events from which to drive the callback.
>
>I intentionally returned just the key, not the data fields.
>You dont want to waste time and bandwidth returning strings or
>blobs for rows you dont want.
>
>You can use the return MLID as an input parameter to extract
>the full row details from another dataset. BUT... this is not
>going to be elegant if you are using data-aware components like
>IB_Grid etc. It is strictly a solution for driving by code and
>feeding to some other control, so I am not sure if it is what
>you need.
>
>You MAY be able to use TIB_Query's OnFilterRecord event to
>keep all rows returned by MYSP and only display matches - and
>then extract the interesting stuff through a detail dataset,
>or through a LEFT OUTER join.
>
>
>The main point is that, in order to give a user feedback, you
>must get a response from the server. Without using threads
>the only way to do it in this sort of situation is to ensure
>that a query will in fact return something to indicate what it
>is doing.
>
>HTH
>
>--
>Geoff Worboys
>Telesis Computing
>
>

__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp