Terminology

[Guest]

I must confess some ignorance here, but what is the best way to view the
concept of a macro in Access.
I'm new to databases but have a long history with various spreadsheet
incarnations, going back to Lotus Symphony. I tend to view macros as being
recorded procedures. In Excel the recorded procedures are converted to VBA
and the VBA code is stored in Modules. (I learned VBA by reading recorded
code first then I bought a book by J. Walkenbach to learn coding at a
slightly higher level.)
The very sturcture of the Access database window suggest that one could
have a library of proceedures stored in modules and another library of
proceedures stored in macros. Are macros simply the set of proceedures
called by DoCmd code?
I'm using Access 2003 Bible to teach myself Access. It's been a good
book for a beginner, but I'm afraid it fell a bit short with this concept.
So my basic question: What Is A Macro?

Thanks,

E.Q.

 

[John Vinson]

I must confess some ignorance here, but what is the best way to view the
concept of a macro in Access.

Something to be ignored, mostly. Macros are a holdover from the old
days; they have functionally been replaced by VBA Modules.

I'm new to databases but have a long history with various spreadsheet
incarnations, going back to Lotus Symphony. I tend to view macros as being
recorded procedures. In Excel the recorded procedures are converted to VBA
and the VBA code is stored in Modules. (I learned VBA by reading recorded
code first then I bought a book by J. Walkenbach to learn coding at a
slightly higher level.)
The very sturcture of the Access database window suggest that one could
have a library of proceedures stored in modules and another library of
proceedures stored in macros. Are macros simply the set of proceedures
called by DoCmd code?

I'm using Access 2003 Bible to teach myself Access. It's been a good
book for a beginner, but I'm afraid it fell a bit short with this concept.
So my basic question: What Is A Macro?

An archaic holdover, almost never needed, and something to be ignored.

Exceptions:

- If you need to use a command line switch to execute something in
Access, you can use the x macroname in the call to msaccess.exe.
- Once in a while an OnKey macro can be handy.

John W. Vinson[MVP]

 

[Duane Hookom]

Macros don't have much useful life as far as most experienced developers are
concerned. You can and should use code for all of your procedures,
functions, etc. There are a few special macros that might be usefull such as
the autokeys macro that can trap key strokes/combinations and perform some
action.

You can also specify a macro name in the command line to kick off when an
application is opened. I have used this when I have a scheduling application
start Access at a particular time of the day and run a specific routine.

 

[Guest]

Thanks,
I'll ignore the concept of macros for now while I'm still learning Access.
But hopefully something will trigger in my fuzzy memory should some of the
exceptions/special situations arise.
E.Q.

 

[Guest]

Hi E.Q.

To add some to what the other's have already written, here is a quotation
that I like to share:

From: "Inside Relational Databases, 2nd Edition, by Mark Whitehorn and Bill
Marklyn, published by Springer, p 151)

"Macros offer the next level down, extending the functionality of the GUI.
Macros are still limited, however, and do not provide anything like the
enormous flexibility of a programming language. Both the macro and the
programming languages take some effort to learn and, surprisingly, often
require relatively different skills; in other words, a good working knowledge
of macros may not make it much easier to convert to using the programming
language. Perhaps even more surprisingly, I do not believe that programming
is fundamentally more difficult to learn. Macros are easier to use but not by
orders of magnitude."

"If you are new to RDBMSs, I suggest (with as much deference as possible)
that you may well not be in a position to judge whether you need macros or
programming. In that case, my advice is clear. Unless you are sure that your
needs really are simple, don't bother learning to use macros. Once you find
that you need more than the GUI offers, go straight to the programming
language. In this way you avoid the pain of climbing one learning curve only
to discover that the view from the top is unsatisfactory and another climb
awaits you."


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

Thanks,
I'll ignore the concept of macros for now while I'm still learning Access.
But hopefully something will trigger in my fuzzy memory should some of the
exceptions/special situations arise.
E.Q.

 

[BillCo]

Something to be ignored, mostly

I was thinking it myself, then I read it - exact words - LOL

 

[Guest]

Best advice I have read on macros. I have always considered macros to be
"training wheels".
If you think about why there are macros, you understand their importance.
Access, from the beginning, wanted to be the database tool for non technical
"do it yourself" types. Since you would expect this portion of the target
audience to have no programming skills, a vehicle to perform actions was
needed. Thus became macros. Easy to use, but very limited in capability.

 

[John Vinson]

Excellent quote! Thanks Tom.

a good working knowledge
of macros may not make it much easier to convert to using the programming
language

The most difficult single project I recall when I was working at my
previous job was to convert a huge nest of macros to VBA code. The
company's client had *insisted* that the (quite complex) operation be
done in Macros because he didn't understand, and feared, code.

The 1000+ lines in the thirty or so macros didn't work completely, and
the operation took many minutes. I finally gave up trying to translate
the macro actions into code, and wrote the VBA from scratch, based on
the functional requirements. Two subroutines, some sixty or seventy
lines, worked correctly in seconds.

John W. Vinson[MVP]

 

[Guest]

Hi John,

I had a similar experience, when helping another person at work with one of
their databases. He had created a mega-macro that had close to 100 steps,
with many of them being update, append and delete queries. Talk about a mess.
I was lucky in that this person was asking for help, without making any
particular demands, such as no VBA code. I converted his macro to code,
streamlined it signifcantly, added error handling, and found that it ran in
about 30 seconds versus the 5 minutes that his macro required. He was doing
an awful lot of data manipulation, using temporary tables, etc. I did not
take the time to try to analyze that mess any further, to see if all of that
was really necessary.

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

Excellent quote! Thanks Tom.

a good working knowledge
of macros may not make it much easier to convert to using the programming
language

The most difficult single project I recall when I was working at my
previous job was to convert a huge nest of macros to VBA code. The
company's client had *insisted* that the (quite complex) operation be
done in Macros because he didn't understand, and feared, code.

The 1000+ lines in the thirty or so macros didn't work completely, and
the operation took many minutes. I finally gave up trying to translate
the macro actions into code, and wrote the VBA from scratch, based on
the functional requirements. Two subroutines, some sixty or seventy
lines, worked correctly in seconds.

John W. Vinson[MVP]

 

[Guest]

Thanks Klatuu.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

Best advice I have read on macros. I have always considered macros to be
"training wheels".
If you think about why there are macros, you understand their importance.
Access, from the beginning, wanted to be the database tool for non technical
"do it yourself" types. Since you would expect this portion of the target
audience to have no programming skills, a vehicle to perform actions was
needed. Thus became macros. Easy to use, but very limited in capability.