>>Andrus,
>>
>>I don't think what you are seeing is a bug. Your check for EOF() in rCursor is not going to work because the UPDATE opens its own copies of the tables and the record pointers in the rCursor alias are not affected by the processing of the UPDATE command.
>
>The SELECT-SQL opens its own copies of tables but the UPDATE-SQL works on already open tables. The following code shows it.

CREATE CURSOR Cursor1 ( Field1 c(10), Field2 T, Field3 I, Field4 L )
>INSERT INTO Cursor1 VALUES ('HLADU', {:}, 0, .f. )
>INSERT INTO Cursor1 VALUES ('POOD', {:}, 0, .f.)
>INSERT INTO Cursor1 VALUES ('POOD-1', {:}, 0, .f.)
>INSERT INTO Cursor1 VALUES ('AAA', {:}, 0, .f.)
>
>CREATE CURSOR RCursor ( Field1 c(10) )
>INSERT INTO RCursor VALUES ( 'POOD' )
>INSERT INTO RCursor VALUES ( 'HLADU' )
>INSERT INTO RCursor VALUES ( 'POOD-1' )
>INDEX ON Field1 TAG T
>
>SELECT Cursor1
>SET RELA TO Field1 INTO RCursor
>
>UPDATE Cursor1 ;
>    SET Field2 = DATETIME(), ;
>    	Field3 = RECNO("RCursor"), ;
>    	Field4 = EOF("RCursor")
>* Field3 has correct record numbers from RCursor
>BROWSE
>

It looks like a bug. However, it still not a good idea to combine set oriented UPDATE-SQL command with record oriented function EOF(). The result could be unpredictable.

If this is not a good idea, how to implement the functionality of this code
using only good ideas ?
Unlike access, vfp doesn't allow to use multiple table names after UPDATE
clause!
Is it possible to implement such update without SET RELATION ?