>>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?
>
>Something else is wrong. I'm actually using couple of .dbcs to keep the updatable views on free tables which reside in another directory, and define them programmatically, starting with what GenDbc gave me. There was a bug of a kind in what it produced - I've had free tables with the same name in different directories, and GenDbc didn't include the proper path to them in the generated routine (namely in the "from ..\otherdir\table" part of the SQL Select, the "..\otherdir\" part was missing), so I had to fix it. It may be doing other things, too. Once these quirks are taken care of, it works fine.

You have defined the problem just right. The DBC can't retain the path for free tables so if the table is not in the current directory sent updates doesn't work. You can't even force the path by using CURSORSETPROP('tables'). I think you're right, it's a bug.
-Dore