Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Tip of the day: using SELECT(0)
Message
From
24/10/1999 11:31:19
 
 
To
24/10/1999 10:51:05
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00280569
Message ID:
00280577
Views:
15
>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.

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.

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, 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.

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

>
>Walter,
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform