Thanks for the suggestion. I tried it but it doesn't seem to work. Whether the free table is in USE before the query is executed or because the query is executed if it's a free table outside of the current directory (even if the non-current directory is in the SET PATH) the association to it for sending updates seems to be lost. The quick check that I do is to ?cursorgetprop('tables') for the local view. If the result to that question is an empty string I know the association is not there. It really seems that the view's table property can't have a path in it though it can have a dbc designator (!).
-Dore
>I've seen this to. I have a local view which is based on a table in my DBC and a free table. I found that if I USE the free table first and then USE the local view I don't encounter any problems. HTH
>
>>Has anyone else noticed this behavior in VFP 5?
>>If you create a local view, either programatically with create sql view or with the view designer, which is intended to send updates to a free table, the view loses it's association to the free table it is intended to update unless that free table is in the current directory or in the same directory as the dbc that holds the view. Even though the table intended to be updated and its full path is explicitly defined for the view (both in the view definition and) by specifying it in the tables property of either dbsetprop or cursorsetprop, any attempt to move the record pointer in the view yields an error message which basically request that the table to update be defined by setting the tables property of the view. The tables property is correct when dbgetprop or cursorgetprop is queried for it but I get the error message anyway. Is there a way to force the view to remember the free table it is supposed to update if that free table is outside the current directory or in a different
>>directory from the dbc?