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)

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()
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.

1 thought on “Restoring Work Areas: ALIAS() vs. SELECT()”

  1. Andrew, I agree with your recommendation about SELECT(). However, something I didn’t realise until recently: SET COMPATIBLE will change how SELECT() works in a devastatingly serious way. From the help file:

    SELECT() returns the number of the current work area if SET COMPATIBLE is set to OFF. If SET COMPATIBLE is set to ON, SELECT() returns the number of the unused work area with the highest number.

    So for goodness’ sake, if you’re writing code for other developers to use, get into the habit of specifying SELECT(0) rather than SELECT(). It’s a lot safer!

Comments are closed.