I use the "IN TABLE_ALIAS" in all table requests, including the SEEK command:
SEEK cMyKeyString ORDER MyDBFTag IN MyDBF

For speed I open all my DBFs at the top of the application and leave them open till the application is closed. I [also] try to design my projects to reduce the need to test for existing data (using IF SEEK() or IF FOUND()) functions.

The benefit of using IN TABLE ALIAS does two things.
1) When a loop or process merges information from several VFP tables, VFP can sometimes get lost.
2) It saves code space - you applcation will not need a SELECT My_Alias statement before the table is addressed.

We used to have a contributer, Ed Raul, who explained all of this to me a long time ago. It is a good practice to be as 'explicit' as you can, especially if it can be "assessed" inside the same end of line as a non-explict phrase.

APPEND BLANK has it too.

Bottom line: It's a good practice. It's fuctional - and it provides commentary as well (the SELECT ALias() statement could be off the page) - at least you know what table is being addressed.

>Hi!
>I need a clarification to see if I'm right.
>This one is just to understand the way things are done.
>When accessing a table in another work area by ALIAS:
> - If using COMMANDS like USE, GOTO, etc. - we add a IN TABLE_ALIAS
> - If using FUNCTIONS like RECNO(), RECCOUNT(), etc. - we must enclose the TABLE ALIAS in quotes, passed as a String, or we got an error saying that "Variable not found".
>My question: Is that because they work as regular function like the ones we create or there is another reason?
>The first time I tried to use RECCOUNT() to operate in another area using table alias I spent a lot of time till I understand this. The VFP Help does not 'Help' in this situation because it does not make a note on this.
>Sorry for all of this.
>Many thanks!