>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.