ACCESS equivalent of dBase "macros"

  • Thread starter Thread starter Paul Farseth
  • Start date Start date
P

Paul Farseth

In FoxPro and dBase, putting an ampersand (&) in front of
the name of a memory variable allowed you to use the
contents of that variable as an instruction in program
code. For example, you could prompt a program user for a
drive and directory (e.g. "H:\MyHomeDrive") and then store
that in a memory variable and use it with the & "macro"
command to control where a file was written, e.g.

MemoryVariable = MemoryVariable + "NewFile.DBF"
COPY TO &MemoryVariable

How would one do this in ACCESS (that is, get the memory
variable's contents to be available to control a process
as part of the code in a module)?
 
Paul Farseth said:
In FoxPro and dBase, putting an ampersand (&) in front of
the name of a memory variable allowed you to use the
contents of that variable as an instruction in program
code. For example, you could prompt a program user for a
drive and directory (e.g. "H:\MyHomeDrive") and then store
that in a memory variable and use it with the & "macro"
command to control where a file was written, e.g.

MemoryVariable = MemoryVariable + "NewFile.DBF"
COPY TO &MemoryVariable

How would one do this in ACCESS (that is, get the memory
variable's contents to be available to control a process
as part of the code in a module)?

I'm not entirely sure what you're asking. If it's just a matter of
using variables in database operations, the VBA language in combination
with the Access object model allows you to use variables in performing
just about any operation you could do via the user interface. Although
Access does still provide a macro language, this is separate from, and
very limited compared to, the VBA language that is supported for
automating Access.

On the other hand, it's just possible you're asking about executing
*code* that is stored in a variable. This is supported in a limited
way: by the RunCode and RunMacro methods, and by the Eval() function
that enables the run-time evaluation of code embodied in a user-defined
function. However, this is probably not what you're asking about.
 
1) You can use VBA in Access. VBA is NOT a macro
language, so you can ALWAYS use variables to control
a process:

v3 = "H:\MyHomeDrive\"
DoCmd.TransferText v1, v2 , v2, v3 + "NewField.DBF", v4

2) VBA was derived from an 'interpreted' languge,
and for backword compatibility still exposes a
command interpretator:

v0 = "DoCmd.TransferText"
Run v0,v1,v2,v3 + "NewFile.DBF",v4

(david)
 
Back
Top