Hi Carl,

I think due to the different syntax and language construction, I find less need in VB for macro substitution. In fact even in VFP, I don't need macro substitution very often. We need it mostly in COMMANDS such as SELECT, REPLACE etc. Many of the situations in which we need to use & in VFP can be addressed in VB by building a string and passing the string to a method/property.

For example to build a SQL SELECT command dynamically in VFP, you would do something like this:

MyField = "Id"
MyTable = "FoxUser"
MyWhere = " WHERE Id LIKE 'WIND%'"

SELECT &MyField FROM (MyTable) &MyWhere

However, in VB, ADO, etc. you often pass a string containing the SQL SELECT to a method. The same applies in VFP when we use SPT:

lcConnectionStr = "Driver={Microsoft Visual FoxPro Driver};" +;
"SourceType=DBF;" +;
"SourceDB=C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VFP98\;" +;
"Exclusive=No;"

lnVFP = SQLSTRINGCONNECT(lcConnectionStr)

*-- build the SQL command
lcSqlCommand = "SELECT " + MyField + " FROM " + MyTable + " " + MyWhere

SQLEXEC(lnVFP, lcSqlCommand)

Or with ADO:

ioRecordSet.Open(lcSqlCommand, This.ioConnection, adOpenDynamic, adLockOptimistic)

In these cases we don't need macro substitution because we use functions or methods that receive the SQL command as a parameter.

HTH