Restoring Work Areas: ALIAS() vs. SELECT()

Most programs like to save and restore the calling environment when they execute. The environment may include settings, work areas and more. This is something that is fairly unique to Visual FoxPro rather than VS environments that don't really have the concept of a work area. In Visual Basic for example, you retrieve your dataset object, execute your commands separately and basically treat it like an object (this isn't about VB so don't flame me on the basic description).

In Visual FoxPro however, you have the concept of work areas. So when you decide to work on the Customer file, you can say SELECT Customer and that becomes your main "area" that you are working with. This can be extremely handy for a variety of purposes. But coming back to the matter at hand, saving and restoring environments.

FoxPro provides you with a few functions that can tell you what you're working with. If you want to know what table you are currently working on, you can use DBF() to return the full file name or ALIAS() to return the alias of the currently selected table. If no table is open, ALIAS() returns blank. ALIAS() is often used when using temporary alias names as shown here:

lc = SYS(2015)
SELECT * FROM CUSTOMER INTO CURSOR &lc
SELECT CUSTOMER
SELECT &lc
...

Why would someone do that? Hard to say - a cursor is after all a temporary name (existing in memory only) but if you are having a rough time coming up with unique names, SYS(2015) always works well.

But Visual FoxPro also has a SELECT() function that returns the current work area. When you first start VFP, you are in work area 1. If you want to select the next unused area, you can say SELECT 0 or type in USE INVOICES IN 0.

So as with all things Fox, there are a number of ways you can accomplish a task, and often the most obvious way may not be quite what you want.

I was recently reviewing some code that was attempting to store and restore the environment. The code used the ALIAS() function.

lcSelect = ALIAS()
SELECT 0
USE xxxxx
** do some other stuff
SELECT &lcSelect

Works great, right? Wrong. This code assumes that lcSelect does have a value in it. If there was no table currently open, lcSelect would be empty. As a result, the final SELECT statement would say "SELECT " - which generates a syntax error.

The smarter approach is to use the SELECT() function. SELECT() returns a work area number and will always (?) give a value greater than 0 but even if it returned 0, SELECT 0 IS a valid function.

Update: As Colin Nicholls noted in the comments, if you use SET COMPATIBLE ON, SELECT() doesn't work the same. (it returns the number of the next unused area - kind of like saying SELECT 0) Instead, use SELECT(0) to be sure you're getting the correct result. Thanks Colin - shows how much I use SET COMPATIBLE.

lnArea = SELECT(0)
** do my code
SELECT (lnArea)

This code won't error out the same way the SELECT (lcArea) does .

It also returns code using the EVALUATION parentheses which is somewhat faster than the & approach.

For many experienced developers, this may seem obvious - but if you're just starting out working in FoxPro, the concepts of work areas may seem a little foreign and you feel better relying on the alias. Don't - work areas are your friends and SELECT() is a very handy function to keep in mind.