You need to look at why the record is going away more closely. Is this because someone else somewhere altered the record to no longer meet the selection criteria? If that is the case, then I would think having it removed from the buffer is the correct action that should be responded to rather than glossed over.

Perhaps I'm missing something here too...

Why does this special case behave differently?

Also, I can tell you, having a select from a stored procedure could be very inefficient when functioning as the single record refresh query. Reason is, there is no caching and indexing of records to pluck out just the one of interest. The entire select procedure has to be executed in whole on the server just to return the single record to refresh the row on the client. This is something that should be avoided. What I would like to do is to allow a customized single record query so that you could design a suite of stored procedures that would handle all the various behind the scenes functionality.

Jason Wharton

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of Daniel Albuschat
> Sent: Friday, December 01, 2006 2:46 AM
> To: IBObjects@yahoogroups.com
> Subject: [IBO] Problem with InvalidateRowNum
>
>
> Hi there,
>
> I have the following setup:
> There's a list of address displayed in an IB_Grid, which is assigned
> to a IB_Query.
> The address itself is displayed somewhere else and gets its data from
> a stand-alone
> IB_Cursor, which basically loads the same data as the IB_Query. This
> was, unfortunately,
> necessary, to control the update behaviour of the main dataset dialog.
>
> Now there's obviously the problem of data synchronisation. The list is
> read-only, so the
> only thing that needs to be done is invalidate a row after it has been
> posted from the cursor.
>
> The usual select-statement looks like this:
>
> select m.* from add_main m where [... some where statements]
>
> This works fine in regular cases. Now there's a special case where the
> select-statement
> of the IB_Query looks something like this:
>
> select m.*, s.cal_type from select_reminder(:calendar) s
> left join add_main m on m.id=s.id_add
>
> The new field in the select-output -- s.cal_type -- is of most
> interest. I don't know exactly
> how InvalidateRowNum will fetch it's row, but obviously it needs to
> get the value for the
> s.cal_type field. But here comes the problem: In some cases,
> select_reminder will not
> return this row because the user has changed some data in the
> main dialog.
> If this is the case, the row will be removed from the Grid after
> InvalidateRowNum has been
> called. This is, however, very unfortunate, because the dataset shall
> be visible in the grid
> until the user hits 'refresh'.
>
> So my question is: Is there perhaps some way to directly manipulate
> the buffer-data of
> an IB_Query? If I was able to do this myself, I could simply
> synchronise the IB_Query
> with the IB_Cursor's field values without refetching from database.
>
> If it's not possible, do you see some other work-around or
> fix to this problem?
>
> Regards,
> Daniel Albuschat
>
> By the way: I'm using an -- as I've been told here -- ancient version
> of IBO: 4.2.Ib, but
> perhaps it is still reproducable in a new version, since it seems to
> be desired behaviour.
> --