>The broken view is a subset of fields from the same table that the Parent view is based on. The parent view updates the base tables. The view that is a subset of the fields in this table is the one that the framework complains does not have the column. It is only broken when running the application, It is fine when opening the view from VFP.

Was the broken view originally a copy of the working view that was filed down to fit? Something from the parent view that should have been removed but wasn't? Is it actually throwing the error on VFP's requery or in VPM code?

>Your 2c is not measly. But I am curious, why were you intrigued?

I try to look at all the question threads, offer advice if I can, learn things to avoid, whatever. Seeing your name on it, I knew it was going to be interesting.

>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?
>
>My gut feel on this is that there is a problem somewhere in VPM's metadata, but I have browsed the metadata tables for the views involved, I can't find anything suspect.
>I am almost ready to give up on this one because the only 2 people who ever see this application working against native data are another developer and me. All the production stuff is against SQL Server. But he asked me to resolve the issue (originally the cascading RI was broken). I fixed that problem, but after I did, it led to a whole bunch of new problems :(

The thought plickens... What was broken in the RI and could it have ANY bearing?

Metadata. Is VPM rebuilding something internally from metadata using field evaluation? Grabbing a field it shouldn't because it started life as a different query?
If you change the query to a field other than CaseNo, does the error still claim CaseNo or the new field?

Chris.