| Subject | RE: [IBO] Refresh problem |
|---|---|
| Author | Jerry Sands |
| Post date | 2004-07-27T13:20:01Z |
Subject: Re: [IBO] Refresh problem
the rows that will be buffered for the application. This is advisable when
your output is likely to be more than about 200 rows.
The output from this stored procedure is almost never more than 5 or 6 rows
of data
No; ideally you should design your SSP with the key columns as input
parameters, since this binds the keys directly to the procedure's
execution: the input part of the SP then doesn't process rows that the
application doesn't want.
This stored procedure has been in use for 5+ years and was originally
designed around the BDE (unfortunately)
the SP completes. This is different from a regular DSQL select, where you
have a "moving window" of rows in the buffer with large datasets. If the
buffer doesn't have a row that it needs, it dynamically "moves the window"
until the required row is contained in the buffer. This isn't possible
with SSP output, since there are no tables to target with WHERE clauses.
If the output isn't huge, you could try putting the dataset into a
BeginBusy...EndBusy loop before calling Refresh; then call FetchAll on the
dataset instead of Open. Then see whether you get the desired results with
the chosen RefreshAction...
Thanks for the suggestion. No difference. This worked perfectly when I
first converted this program from BDE to IBO using TIBOQuery and the
standard Delphi controls. This behavior started when I converted to
TIB_Query and IBO controls. The data in the last row that is not showing
will show up if the previous row is selected (the dataset is scrolled in
reverse).
Jerry Sands
>When I use a RefreshAction of raOpen the refresh works correctly but theYou can call a SSP with a WHERE clause on the input parameters, to limit
>currently selected row always is the first row, which is not what I want.
the rows that will be buffered for the application. This is advisable when
your output is likely to be more than about 200 rows.
The output from this stored procedure is almost never more than 5 or 6 rows
of data
No; ideally you should design your SSP with the key columns as input
parameters, since this binds the keys directly to the procedure's
execution: the input part of the SP then doesn't process rows that the
application doesn't want.
This stored procedure has been in use for 5+ years and was originally
designed around the BDE (unfortunately)
>Does anyone have any idea why this behaves this way. Since the data doeskeeping
>show up after the result set is scrolled I would assume something is
>it from getting buffered before that time.Correct; the whole "catchment" of rows doesn't exist in the buffer until
the SP completes. This is different from a regular DSQL select, where you
have a "moving window" of rows in the buffer with large datasets. If the
buffer doesn't have a row that it needs, it dynamically "moves the window"
until the required row is contained in the buffer. This isn't possible
with SSP output, since there are no tables to target with WHERE clauses.
If the output isn't huge, you could try putting the dataset into a
BeginBusy...EndBusy loop before calling Refresh; then call FetchAll on the
dataset instead of Open. Then see whether you get the desired results with
the chosen RefreshAction...
Thanks for the suggestion. No difference. This worked perfectly when I
first converted this program from BDE to IBO using TIBOQuery and the
standard Delphi controls. This behavior started when I converted to
TIB_Query and IBO controls. The data in the last row that is not showing
will show up if the previous row is selected (the dataset is scrolled in
reverse).
Jerry Sands