Hello Nadya,

Well, I think Larry has given you the answer, or at least a variation of the correct answer. Do a SEEK, and then do a REPLACE WHILE...I think it will be the best performance you can get.

>>I don't think it would be fully optimized, and the little test I just ran (using sys(3054)) seems to confirm that. However, as Hilmar has said, it may not be a problem.
>>
>>Is this data stored in VFP tables? Why are there nulls, and can they be permanently eliminated?
>>
>
>Hi Steve,
>
>Yes, data is in VFP tables, NULL inserted automatically, when user empties the field. We had a meeting on Monday, that for incoming data we should not insert nulls (so, perhaps, we would need to change all applications in regard to this), however, for database maintenance operations we need to insert nulls, so our Update engine will know, what we need to clean up data in the main database. This is a rule for Update engine...
>
>>>
>>>Right, the REPLACE statement should be changed as well. Why do you think, it would not be Rushmore optimizable? Do you remember, NVL in index expression does automatically turn expression to be non-optimizable?
>>>>