Subject | Refresh problem |
---|---|
Author | Jerry Sands |
Post date | 2004-07-26T19:26:01Z |
I have a TIB_Query that selects rows from a stored procedure. The problem
is when I call refresh for this TIB_Query using a RefreshAction of
raKeepRowNum or raKeepDataPos, and the current row is the last row of data
in the result set, the data for that row will not show up in a connected
TIB_CtrlGrid. All the columns of that row when accessed with FieldByName
return null as well. If I cause a scroll of the dataset programmatically or
by clicking on any other row in the TIB_CtrlGrid the data will show up both
on the TIB_CtrlGrid as well as when accessed with FieldByName.
When I use a RefreshAction of raOpen the refresh works correctly but the
currently selected row always is the first row, which is not what I want.
The stored procedure pulls columns from multiple tables. It will sometimes
even generate an additional row of data as needed by the application. It
generates a row number for each row it outputs and that column will always
be unique but if a row of data is removed from the database the row number
will change on all data that is output after the deleted row so it is not
necessarily a good candidate for keylinks.
Does anyone have any idea why this behaves this way. Since the data does
show up after the result set is scrolled I would assume something is keeping
it from getting buffered before that time.
Thanks
Jerry Sands
[Non-text portions of this message have been removed]
is when I call refresh for this TIB_Query using a RefreshAction of
raKeepRowNum or raKeepDataPos, and the current row is the last row of data
in the result set, the data for that row will not show up in a connected
TIB_CtrlGrid. All the columns of that row when accessed with FieldByName
return null as well. If I cause a scroll of the dataset programmatically or
by clicking on any other row in the TIB_CtrlGrid the data will show up both
on the TIB_CtrlGrid as well as when accessed with FieldByName.
When I use a RefreshAction of raOpen the refresh works correctly but the
currently selected row always is the first row, which is not what I want.
The stored procedure pulls columns from multiple tables. It will sometimes
even generate an additional row of data as needed by the application. It
generates a row number for each row it outputs and that column will always
be unique but if a row of data is removed from the database the row number
will change on all data that is output after the deleted row so it is not
necessarily a good candidate for keylinks.
Does anyone have any idea why this behaves this way. Since the data does
show up after the result set is scrolled I would assume something is keeping
it from getting buffered before that time.
Thanks
Jerry Sands
[Non-text portions of this message have been removed]