Subject | Problem with InvalidateRowNum |
---|---|
Author | Daniel Albuschat |
Post date | 2006-12-01T09:45:59Z |
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.
--
eat(this); // delicious suicide
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.
--
eat(this); // delicious suicide