>

>SELECT Field FROM Table INTO Cursor Test
>IF _TALLY != 0
>
>ENDIF
>

>
>Is that really so difficult?



Sorry, Craig, you really lost me here. What does this have to do with my example?
I don't think you're seeing it.


To emphasize, the recordmanagers class is to hide certain complexity and make XBASE commands on cursors/tables available in an OO manner without having to worry about things like restoring workarreas, alias names, error handling etc.

Walter,




>>Graig,
>>
>>>How will you deal with a set of records? Have you run timing tests to compare this to using cursors. BTW, I think cursors are a better way to go in VFP.
>>
>>Its a wrapper around a cursor. The main benefits are that you don't have to know the alias, don't have to think about error handling, restoring the current workarea etc. The alias is set once and forget about it. Just look at the implementation. Under the hood its just performing the same XBASE commands, so you can expect the same performance. An exception is the accessing (reading and writing of the fields err. data properties) which is about 100 times slower, but still in the order of 100.000 I/Os per second.In most implementations that is not a big deal. If you need to process a lot of records, you can still execute the XBASE or SQL commands directly on the cursor. There is no conflict.
>>
>>The main reason for me to develop this is to get away from writing the same code again and again... e.g.
>>
>>

>>nSel = SELECT(0)
>>TRY
>>     SELECT (cAlias)
>>     LOCATE FOR ....
>>     lRet = FOUND()
>>CATCH TO oErr
>>    .....
>>ENDTRY
>>SELECT (nSel)
>>RETURN lRet
>>

>>
>>Instead now I can do a
>>
>>

IF oRm.Locate(cExpr)
>>   ..... yadayadayda
>>ENDIF

>>
>>IOW, forget about the alias, forget about restoring alias, forget about the hidden complexity
>>
>>Walter,