Are there any SELECT * queries? I know those complain the most when the structure behind them changes.
Have you used a tool (Code References/GoFish) to look for CaseNo? Does another alias than the ones you're looking at have it?
Are you using a subquery or temporary table that might have that fieldname?
Don't know Promatrix; does one of its Business Objects have a reference to that fieldname?

I thank you for trying to be of assistance. However, the point that you are missing is that this behavior is only exhibited after cascading the modified PK to the child tables (which is does successfully). I do believe that if the problem were the view definition, this behavior would occur all the time - not just when the PK changed.

To answer your question about the CaseNo field. Of course it is in other tables - it is the PK of the parent table and the FK of the child tables.

Also, as I said earlier, the exact same code works fine without any problem when running against remote views. This is strictly a native data issue. But I simply cannot figure out what the problem is. The view definition selects 2 fields from the FuneralCase table (yes, one of them is CaseNo) and both fields are in the FuneralCase table. The view can be requeried successfully with no problem (even against VFP data) until the PK is changed and the change is cascaded to the child tables.

VPM relies heavily on metadata. I was wondering if the problem arose because I had renamed the Case table to FuneralCase. But I checked all the metadata and there are no references in it to Case.dbf. The references all now point to FuneralCase.dbf.