Geoff,

That sounds very similar to my situation. I have a stored procedure
in the EditSQL which needs a unique key to be able to edit (or
insert/delete). This is fine in theory, but I can't actually pass a
unique key from the 'virtual' records (unless I get it to generate
one, but then it doesn't exist in the DB).

What are you using in the 'keylinks' property? My program would
appear not to need anything here, but I get the message 'cannot open
cursor without key data' when I try to edit the figures in the grid.

--- In IBObjects@y..., "Geoff Worboys" <geoff@t...> wrote:
> > That is what I'm doing! The problem is that I don't have a
> > unique key field (as, in some cases, the data, i.e. the
> > zeroes, doesn't actually exist in the database).
>
> I have something similar with timesheet entry. I have a grid
showing
> all inputs for all 7 days of a week, but the corresponding records
> dont necessarily exist.
>
> The select stored procedure simply passes back 7 records (filling
out
> the day's date with zeros or nulls for those entries that dont
exist).
> There is no insertsql or deletesql, since the user cannot create or
> destroy days - they already and always appear to exist. The EditSQL
> simply accepts the input parameters - using the date to control the
> insert/edit/delete process. If all the input parameters are zero I
> delete the corresponding days record, if non-zero values are given
> then I insert or edit (depending on whether a record exists or not).
>
> Since the editsql procedure does various validation and limitation
> (the person cant work more than 24hours in a day :-), it is
necessary
> to dynamically refresh the grid after EVERY post. The only way of
> getting the dynamic feedback required in this situation is to call
> RefreshAll after posting any record, since it is not possible to
> refresh an individual record returned from a stored procedure.
>
> nb. Jason and I have discussed trying to provide a separate select
SQL
> property to allow the specific refresh of an individual record (when
> everything else is based on stored procedures) but this has not
> eventuated - perhaps sometime in IBO4.
>
>
> This arrangement would not be practical for large grids, but for
small
> stored procedures returning a small selection this seems to work
quite
> well.
>
>
> Does this help?
>
> Geoff Worboys
> Telesis Computing