John,

I too think there's a lot of macro substitution that can be done away with . I actually try very hard to avoid it as much as possible. For me, removing it would be like trying to remove one large artery. <g> It's so intertwined that in the process of the removal you stand a good chance of killing the patient.

I am curious though, if you don't mins, if you could answer a question or two. I know you're a big proponent of ADO, VB, etc... In the cases where someone might want to "data drive" their app how does one typically go about this in VB? I'm prtyy unfamiliar with how it handles this type of issue.

For example, let's say you have three sets of data: Development, Test and Production. The Development data is used only for that - development. The Test and Production data are used for those two respective purposes with the addition that the Test data is also used by developers as they deploy a new build.

Typically, how would you approach the issue of activating the appropriate set of data at the appropriate time?

Best,

DD



>FWIW it's worth Erik, I agree with you here...
>
>Macro Substition is an over-valued feature...
>
>>>No way! Macro substitution is one of the most useful features in VFP.
>>
>>Why? What do you use it for that couldn't easily be replaced? AFAIC, the only legit uses for macro substitution are constructing SQL statements, and the few places where they are necessary because a command doesn't accept a named expression. Except for these, most other uses for macro substitution should be replaced with other methods like EVAL(), or just a refactor.
>>
>>I would throw away macros altogether if we had the equivalent of the two following imaginary functions:
>>
>>=RUNSQL("SELECT * FROM MyTable INTO CURSOR Whatever")
>>
>>=SETENV("EXCLUSIVE", "ON")