>Hi Jim. The cold medicine is starting to kick in... I can be more verbose now. I'll cut and snip and bit to get to the points that I was interested in.

Evan,

Hope that cold gets better.

>>3: & the macro expansion feature is too often used where it is either not necessary or ther is a bettter way to accomplish the same goal.
>
>The alternatives are named expressions and evaluate, as Nancy mentioned. Is there anything else you would recommend.


There are also situations where I ahve seen a macro used and there was no need for it or any of the alternatives. Someone else posted an example;

SEEK "&VarName"

>>4: Filtered indexes, are often used where they are not necessary. The same result can be obtained using SQL without the overhead of having an extra index tag around all the time.
>
>Not sure what a filtered index is. Is it an index like "age > 18"?

A filtered index is one with a FOR clause on it.

INDEX ON Name FOR State = "NY" TAG NyFolks

>>5: UNIQUE indexes, not only are they misused but they could easily be totally removed from the product without any alteration in capabilities.
>
>I have never understood these and have avoided them.

That is a very good approach to anything we don't fully understand. Unfortunately, many times folks will use something they don't fully understand and I have seen people recommend to others to use things that the suggester doesn't fully understand.

>>6: PUBLIC variables are often used in situations where they are totally not required.
>
>Would the alternative be a property of an application object?
>instead of gcLoginName you would use oApp.cLoginName ?

That would be one alternative. However, I am referring mostly to the fact that many people believe that to have a variable with a visibility that extends to an entire application it is necessary to declare it as public.

>>7: SET EXACT is often used to cover for not understanding the way strings are compared in xBase. This causes the loss of a lot of functionality that is inherent in the product in order to adapt to a lack of knowledge.
>>
>>8: == is often NOT used where it should be. See SET EXACT above.
>
>You are advocating = and == over SET EXACT, why?
>I use = and == for more control and it seems more self documenting.

Again, I am advocating understanding what each of them do and how they can be used effectively. SET EXACT ON and == are not the same thing. Contrary to the name of the setting, SET EXACT ON does not cause exact comparison of strings. Examples;

lcVar1 = "John"
lcVar2 = "Johnson"
lnVar3 = "John     "

SET EXACT OFF
?lcVar2 = lcVar1  && .T.
?lcVar1 = lcVar2  && .F.

SET EXACT ON
?lcVar2 = lcVar1 && .F.
?lcVar2 = lcVar3 && .T.

?lcVar2 == lcVar3 && .F.

The difference is that SET EXACT (or SET ANSI for SQL) pads the shorter string with spaces before comparing them, while == compares the same as SET EXACT OFF and then checks for them being the same legnth. Therefore whenever the difference between two strings is trasiling spaces SET EXACT ON will find them equal while == will find them NOT equal.

>>10: PACK is too often sued in situations where any benefit it porovides is far outweighted by the costs associated with it.
>
>I don't understand. Could you explain?

The need to use exclusively in multiuser environment and tiem required to complete a PACK on a large table plus the vulnerability of the table during the process, in my opinion, are a very strong argument for recycling deleted records instead of packing the table.