>The error message indicates a structure issue; it seemed prudent to focus on that.
>If it were a structural issue, wouldn't it happen all the time and not just when the change in PK is cascaded to the child tables?

Never vouched for the accuracy of Fox's error messages. <g>

>What were the original and changed PKs? Does it fail for only a specific change or all PK changes?
>The RI routine works just fine. It is after the RI code runs that the problem occurs. And it only occurs when using local views. The problem does not occur when using remote views

I get that; just looking at repeatability of the error to help chase it down. If only one PK change causes the break, I start thinking data; if all of them do, I start looking at code. I agree with Craig's advice that something else called during the process is the next place to look. Any UDFs in the view definition or indexes?

>Does changing the PK back to original value "fix" the problem or stay broken?
>I can't do that. After the PK is changed and cascaded to the child tables everything is broken. It can't even find the column caseno in the parent view.

Parent view? Does this mean the broken one is a view of a view? Is the parent view the broken one?
Is it broken only in the program or will the view not open manually in Fox either?

>Thanks for sticking with me. How long have you used VPM?

Ummm.. never, actually. Saw your name on this and was intrigued enough to offer my measly 2c.
And some of these ideas are SWAGs. Even if they don't work they may spark some other idea, or at least eliminate the impossible as that Holmes guy said.

Maybe there's subtle data corruption in the DBC? Delete and recreate the view. Validate the DBC. What forces Fox to reread the view definition from the DBC if the view is already in use? (I don't know that much under the hood stuff.) Some people have separate DBCs for views, is /that/ DBC broken?

Chris.