cursors can be faster than arrays, but mostly when searching utilizes the btree index.
Here the "search" is only accessing the offset, which should not result in a speed benefit.
a "go fieldz in cData" reaches the record without index ;-)

While your code probably is a minimally faster than a "proper" SQL-Update via join,
the "mechanics" are similar. If vfp arrays using fixed offset and singular (not row/record returns)
are slower in this UC I will be surprized....

As only single values are returned, stuffing a single record and eval("cdata.f"+Str(fieldZ,1) would work as well
(with 1 record cursors or an object called cData and addpropertied the right values)
and I guess be faster then a seek/join solution or the string massage.

regards

thomas


>Well, this being Foxpro, why not use a cursor (or even better a table that it can be updated for future values), something like:
>
>

>CREATE CURSOR cData (PK I, Value I) && If this is a table then we have flexibility for future PKs and/or updated values
>INDEX ON PK CANDIDATE TAG PK
>
>INSERT INTO cData (PK, Value) VALUES (1, 24)
>INSERT INTO cData (PK, Value) VALUES (2, 34)
>INSERT INTO cData (PK, Value) VALUES (3, 50)
>INSERT INTO cData (PK, Value) VALUES (4, 59)
>INSERT INTO cData (PK, Value) VALUES (5, 74)
>INSERT INTO cData (PK, Value) VALUES (6, 84)
>INSERT INTO cData (PK, Value) VALUES (7, 97)
>
>REPLACE FieldZ WITH IIF(INDEXSEEK(FieldZ, .t., 'cData', 'PK'), cData.Value, FieldZ) && or null or -1 or whatever
>
>or
>
>REPLACE FieldZ WITH cData.Value FOR INDEXSEEK(FieldZ, .t., 'cData', 'PK') 
>
>or
>
>UPDATE myTable SET FieldZ = cData.Value Select cData.Value from myTable join cData on cData.PK = FieldZ
>* Probably wrong as I wrote it from memory and my memory is bad 
>