>>>I have a perplexing error that occurs when trying to update a cursor using the replace statement.
>>>The error generated is 'Record in use by another user.' Which is unapropriate because the cursor/view is open exclusively in the current datasession. Here is the code that bombs:
>>>
>>>replace ;
>>> data_data with m.lcData_Data, ;
>>> longdata_data with m.lcLongdata_data ;
>>> in griddata
>>>** Longdata is a memo
>>>
>>>Here is a brief list of foxpro system parameters:
>>>
>>>* sys(2011) returns 'Exclusive'
>>>* buffermode is 3 (optimistic row)
>>>* rlock() returns false (but I checked and this seems to be the effect on all views)
>>>* the view recno is on the record to be udpated. (eof, bof are .f.)
>>>* the current alias is griddata, so it shouldn't pose a problem.
>>>* the view is not updatable (its just for visual appearance inside a grid) I update the base table elsewhere.
>>>* calling flush and any combination of tableupdate has no effect on the error message.
>>>* "ignoring" the error causes the data not to be updated (which is unacceptable).
>>>* replace any field in the view results in the same error (ie replace data_data with 'x').
>>>
>>>This error only seems to occur when data is entered into the grid in rapid succession, so it may be a timing issue. As far as I can determine, this is NOT a record locking issue like the msg would imply.
>>>
>>>Has anyone experienced this and/or knows of a workaround. MS knowledge base is not working this evening so I couldn't check it :(
>>
>>I'm a little confused here:
>>- Is it a cursor or a view? You can't modify data in a cursor
>>- Do you do the REPLACE in the view (which is not updatable)? If so, you have to make it updatable if you want to modify it
>
>I have seen this error again and again. I am currently experiencing 'File is in use by another user'. There are generally a few things I found.
>
>Sometimes, when the grid's cursor position gets out of syn with the table/view record pointer, you get one of the two errors. Also, you have to be very careful when you save and restore record pointer. To be safe, do 'RECNO('XXX')' with the alias instead of assuming the current alias. Also, try to do GO (area) IN xxxx instead of just GO (area)..
>
>BTW, I can get rid of 'File is in use' by just having a MESSAGEBOX prompt before BEGIN TRANSACTION.
>
>What can I say? I guess that is why VFP never gets popular with developers.

A lot of troubles that people have with VFP are because of the power of its commands. Where VFP allows you to issue 'recno()' with no alias specified and just assume that you know what your current alias is, other tools might force you specify an alias. So programmers leave out the alias name and have problems because they expected 'recno()' to return the pointer location in a different table. This is not VFP's fault. This goes for all of the commands that allow but don't require that the alias be specified.
As for your discovery that a messagebox gets rid of your error, I would venture a guess that you have found a way around a problem with your technique that you have yet to find the source of. (In other words, lack of a messagebox is not a problem). You have implemented a workaround, where further investigation into the problem will probably reveal its real source. (This is not to say that workarounds are never necessary- they are, in VFP just as in any other language).
I spent my first few months of learning VFP cursing and wishing I could do so and so like I could with Powerbuilder, or such and such like I could with Visual Basic. But after learning the VFP way of doing things, new solutions become intuitive, and problems reveal themselves faster. After learning my way around VFP though, I hope that I will never have to use either of those primitive tools again (VB and PB).

You might find that many of the problems you are experiencing might be solved with careful coding and faithful implementation of OO design. Letting objects handle, look out for, and clean up after themselves will kill _MANY_ problems before they bloom. This involves making sure that you specify an alias _every_ time you issue a command that operates on a specific table. This forces the function to 'look out for itself'.
You are right that VFP has problems. Every language does. But if the 'problem' is that the technique needed to accomplish a certain task is counterintuitive or poorly documented, can this really be called a bug? These 'features' of VFP are what give it a steep learning curve, but I do not feel that they impact the quality or usefulness of the tool.