Hello, Lester and Helen (and anyone else):

Thank you kindly for your replies, but a few essentials are being missed that I
think are important, but perhaps not, since I'm really pretty much of a newbie
with FB/IBO:

1. This is a desktop, FB embedded, Local application, thus there is no server to
pass the operation over to and let it run. Everything stops in the application
waiting for FB to return the query. Thus the need to let the user know.

2. Helen, the only reason I used IB_Cursor was because the original IBO posting
about using OnCallBack suggested it. To be honest I had no idea that a cursor
would return only one row at a time and then lose it. That being the case, I'm
returning to IB_query, because I do need to step through the result set or
perhaps display it in a browse (may need IBOQuery for that, since I use Infopower
components).

This routine is used for searching an encrypted blob or string and as such is
only used for those unusual times when just looking at the STARTS WITH characters
are not needed (perhaps only 10% of the searches or less)--this form of search
works very quickly. And even at that, the search routine is only used once in a
while. I know that it basically is NOT good; I don't like it either; but keeping
the data obscure is more important than making the user have to wait a little bit
for what will probably be a once in a great while search--but I want it there for
this kind of search. (other suggestions where developing a full text search
system and that is just out of the picture at this time.)

3. The bottom line at this point is that I cannot even get OnCallBack to fire at
all. I've tried debugging and its code is never accessed at all.

4. Helen, I've modified the SP to SELECT COUNT(PK) from TABLE into :VAR to get
the full count and pass that back as an output param to the SELECT PROCEDURE
query in the IB_Query. Everything works well when I check in IB_SQL. Thanks for
the suggestion.

I feel like I'm missing something really basic here.

Chuck

Here's the original post in IBO group, April 2, 2004:

hello Enrico,

suppose you have a stored procedure more or less like this:

SET TERM ^ ;

DECLARE PROCEDURE MYPROC(PARAM...optional)
AS
BEGIN
FOR SELECT FIELDNAME FROM MYTABLE DO
BEGIN
....
YOUR PROCESSES HERE;
....
SUSPEND;
END
END ^

SET TERM ; ^

Now, in Delphi code, you can use an TIB_Cursor with the following SQL
statement:

SELECT * FROM MYPROC /* FOR UPDATE */

Remember to assign a proper callback method to the OnCallback property
of the TIB_Cursor used to "open" the stored procedure and to set its
CallbackInc property accordingly, for example your procedure could
update a progress bar using the CursorRowNum variable of the callback
procedure:

MyProgressBar.Position := Trunc((CursorRowNum / TotalRows) * 100);

But you can do even more, for example you can have your procedure
returning values indicating the current row num (I use it in addition
to the progress bar to update a label).

Adding my two cents to what Jason said in his last message, I have to
say that I have not used the "FOR UPDATE" clause and my callback works
very fine and the progress bar and the labels are updated smootly. But
in this case I'm using Firebird embedded with a local connection.

HTH
Salvatore