>>>Frequenly I see people use the following kind of structure:
>>>
>>>cAlias=ALIAS()
>>>
>>>do something...
>>>
>>>IF !EMPTY(cAlias)
>>> SELECT (cAlias)
>>>ENDIF
>>>
>>>
>>>This can be done much easier by:
>>>
>>>nWorkArea = SELECT(0)
>>>
>>>do something
>>>
>>>SELECT (nWorkArea)
>>>
>>
>>Walter, I see one frequent source of problems with thios approach, mostly having to do with situations where you're in a workarea with no table open when you start. At least in my case, I often use constructs like USE some table IN 0 AGAIN ALIAS some alias, and in many cases, I'll leave the table, cursor or view that I opened open when I leave a function or method (basically in situations where I don't open a reference table until it's needed, and then leave it open in the current data session in case I need to get to it again.) In many cases, the file will end up in the workarea that I was originally in, and so selecting that workarea leaves me at least potentially in an unexpected state. Using the alias rather than the work area, I can then say:
>
>>

 IF ! EMPTY(cInAlias) AND USED (cInAlias)
>>   SELECT (cInAlias)
>>ELSE
>>   SELECT 0
>>ENDIF

>>
>>giving me a more consistent behavior.
>
>In this case, I agree. I was referring to the most common situation where you want to select the table that was selected before a certain piece of code was run. If no table was open in the current area, it likely does not matter that on exit of a certain funtion or procedure the workarea is now occupied by a certain table.
>

No but it's likely that I don't want to have that table, view or cursor selected when I return from the function or method call.

>>This also covers the situation where you change what table, cursor or view is referred to by the alias; if the alias is moved to a different workarea, again, you may not have what you expected to find using the numeric workarea reference.
>
>I cannot see any practical situations where you actually want to move an alias from one workarea to another
>

It's not a matter of wanting to - I don't care what workarea is being used for a given alias, as long as the alias is in use. It's often an issue when trying to design stateless COM servers; it's best not to count on the data environment being exactly the way you left it if several clients are referencing a single-use COM server in serial fashion where the sequence of actions is not necessarily predictable, and where method calls from several clients may run interspersed with one another.

It may be an accident of fate - I may close tables and views and the DBC and reopen them in order to ensure that data is forced out to a server or at least to the Windos disk cache.

>>At this point in time, I use this approach on a consistent basis, and I know what I can and can't expect from doing this. YMMV; I prefer the extra level of confidence and familiarity of coding style from doing things this way.
>There's nothing saying you have to do it my way,;
>
>Of course not, but if you look at the example I gave, In many (if not all) practical cases the second option would require less coding, seems to be more straightahead, and improves readability for that matter.
>

I disagree here, but I'm used to how my code looks. I like independence from the concept of a work area, preferring the alias, since that's how I think about my data.

>> any more than you have to declare a .DLL entrypoint immediately before using the API call (with a few exceptions; I declare GetLastError() almost immediately on startup because of potential problems with lost error conditions declaring it after an error with an extended error code occurs.) I've been told that doing the DECLARE...DLL each time isn't as quick as declaring it once, but I find that the security of doing the declaration jsut before using it pays off for me; I'm less likely to get caught by someone else doing a CLEAR DLLS after i did my declaration, and I often declare an API call differently at different times in code, to make working with structures and pointers easier.
>
>Well I agree, I also tend to do this. Maintainability is improved when the DECLARE is issued just before it is called.
>
>>Again, I think it's more an issue of programming style and anticipated behavior rather than a right or wrong way to do things. I doubt that the overhead is a major issue here, and I doubt that the readability and understandability of the code is strongly affected.
>
>Strongly affected ? No of course not, this example however is only showing one alternative to the common approach and seems to be more straigtahead.
>
>>The issue is somewhat along the lines of naming conventions for variables, fields and objects; it's important that you have a standard way to do it, and that you do it that way in a consistent fashion.
>
>This is absolutely true !
>
>Walter,