PMFJI, but have you tried setting the modal form to 'default datasession'? This tells it to use the datasession of the
calling form, (not the 'real' default datasession) and may solve your problem.
It's a workaround - I can't do any more than Erik has already done on the original problem.
Barbara
>>Just to make sure we're on the same page, let me tell you, step by step, how I handle this (I do what you are trying to do all the time).
>
>Yes, that's what's baffling. I'm not trying to do anything weird,
>here. It's not a current problem, since closing the underlying
>table has "fixed" it, but naturally I'd like to know what I'm doing
>wrong.
>
>>DELETE
>>TABLEUPDATE()
>>REQUERY()
>
>About the only thing I'm adding to this (which I'm sure you do as well),
>is finding the next record to sit on. But that happens after the update
>(hence after the error).
>
>>The add button calls a modal add form that uses the same updateable view.
>
>This is a big difference, though. My add form uses base tables, not
>a view. And it does seem that the change to the base table in the
>private DS is _somehow_ not getting reflected in the view's base table
>on return to the view-based form (although BROWSE shows the contents
>are the same, and GetFldStatus() shows nothing has changed).
>
>>I'm sorry if my efforts at help sound repeated, but this has got me really scratching my head...
>
>Not at all, Erik. I appreciate your efforts. I don't think this is
>going to be solvable from your end, but thanks anyway.
>
>On another topic, I can't use the offline viewer. It hasn't worked
>for a couple of days, now (some "unknown error"). Have you seen this?