Subject | Re: [IBO] Confusion about StoredProc vs use of Cursor or Query (was Help with OnCallBack) |
---|---|
Author | Chuck Belanger |
Post date | 2005-07-04T15:39:15Z |
Thank you, Geoff for the reply.
Just in case you need this information: I'm using IBO 4.2Ie.
It took me a little while to find the DoCallBack and SysFetchNext procedures,
until I figured out to include the *.IMP files in my search.
DoCallBack seemed to never be called, except perhaps at the very end when the
query was finished.
SysFetchNext was called on the first row to be fetched but it looks like the
property FETCHING was always false. I assume that this should be true. I
noticed, also, that FCursorRowNum was incrementing properly, too. There's a
WHILE loop in SysFetchNext which just kept looping until the end of retrieving
the dataset.
Finally, at the very end of all the rows of the query, FETCHING became true.
I have no idea what all this means or why the dataset is not seeing FETCHING as
true for each row retrieved. I tried searching for FETCHING and could not find
where it is defined, so have no idea what things determine its boolean state.
I tried various settings in the Query that have to do with "Fetch" with no
change.
Do you have any other ideas?
BTW, CallBackInc has been 1 all along. Some others recommended keeping it al 5.
In any case there was no change in the overall behavior. I even tried changing
the two other CallBack related properties without any effect.
The stored procedure has a SUSPEND, too. I thought this would induce the fetch.
Since I have done everyone else's suggestion for properly setting up the SP, and
the Selected SP and the OnCallBack event, it seems that I must be missing
something very basic, yes?
Thank you answering this,
Chuck Belanger
Geoff Worboys wrote:
Just in case you need this information: I'm using IBO 4.2Ie.
It took me a little while to find the DoCallBack and SysFetchNext procedures,
until I figured out to include the *.IMP files in my search.
DoCallBack seemed to never be called, except perhaps at the very end when the
query was finished.
SysFetchNext was called on the first row to be fetched but it looks like the
property FETCHING was always false. I assume that this should be true. I
noticed, also, that FCursorRowNum was incrementing properly, too. There's a
WHILE loop in SysFetchNext which just kept looping until the end of retrieving
the dataset.
Finally, at the very end of all the rows of the query, FETCHING became true.
I have no idea what all this means or why the dataset is not seeing FETCHING as
true for each row retrieved. I tried searching for FETCHING and could not find
where it is defined, so have no idea what things determine its boolean state.
I tried various settings in the Query that have to do with "Fetch" with no
change.
Do you have any other ideas?
BTW, CallBackInc has been 1 all along. Some others recommended keeping it al 5.
In any case there was no change in the overall behavior. I even tried changing
the two other CallBack related properties without any effect.
The stored procedure has a SUSPEND, too. I thought this would induce the fetch.
Since I have done everyone else's suggestion for properly setting up the SP, and
the Selected SP and the OnCallBack event, it seems that I must be missing
something very basic, yes?
Thank you answering this,
Chuck Belanger
Geoff Worboys wrote:
> > The Stored procedure has SUSPEND and returns multiple rows
> > and has ROWCOUNT to pass for the CallBack.
>
> > I'm using the Query.SQL as in SELECT * FROM MYSP.
>
> > Do I need to add a TIB_StoredProc and use that OnCallBack to
> > make the progress meter step?
>
> No. OnCallback occurs entirely within the TIB_DataSet based
> on a combination of rows fetched, the time elapsed and the
> properties you have set. ie. Make sure you have set
> CallbackInc to 1 or more.
>
> Set a breakpoint in the procedure
> procedure TIB_Dataset.DoCallback;
>
> to try and catch what is going on. If the breakpoint is not
> getting hit there then place a breakpoint in the
> procedure TIB_Dataset.SysFetchNext;
>
> This should allow you to discover why your particular callback
> does not seem to be firing.
>
> --
> Geoff Worboys
> Telesis Computing