I'm really just trying to understand. The reason they keep it locked is because of security. Allowing the user to edit the VCX after instantiating object(s) from the VCX would be like "giving the pilot open heart surgery while in mid-flight".

I'm not sure what advantage you could gain by being able to change the VCX and then force Foxpro to reload all its objects back into memory. I supposed any advantages would be outweighed by the risks of allowing this.

>The VCX is locked to protected against changes in a class when instances of that class exist. The way this all works and it's results/behavior is very unlikely to change, but I'm not sure if you are just trying to understand how the internals work better or if you are wanting some alternative behavior.
>
>Ken
>
>>My understanding of what actually goes on when something is cached is limited. I thought that a copy of what is cached was placed in memory. If that is true then a cached VCX table would not need to stay open because a copy of the table is in memory. But when you are referring to a "special way", do you mean that the table needs to remain open as part of the caching?