Programming with VBA and Macro

[Programming]

I created my first database project in Access. And I intend to set it up in a local network to be used among 4-5 people.

Some of the programming was in VBA and some in Macro.
My Questions is , will I have problems because of the some of the functionalities are in macro and some are in VBA?

The reason I did it like that , is because I am learning/searching along the way of creating the project. When I find an answer about what I want to program I use it .

Plz advice.

 

[JHB]

As I know, there are no problems mixing Macro and VBA code.
But VBA code gives you more flexability and options.

 

[jleach]

It should not present any specific problems. There's no reason macros and code can't intermix within an Access project.

 

[isladogs]

Agree with previous two answers. However if you need help at any point, be aware that few of us here use macros so are less likely to be able to assist with those.

 

[Pat Hartman]

One of the reasons that experts avoid macros is that in the past, there was no error handling support so errors would cause total failures in production environments. Just make sure you have error handling wherever it is needed.

And do not forget that your application should be split into FE (forms/reports/macros/queries/code) and BE (tables only)

The BE is stored on a shared network server and the FE is distributed so that each user has his own personal copy.

 

[Jeffr.Lipton]

I use both macros (for simple things, like closing the current form, or for things that are hard to do in VBA, like exporting to EXCEL) and VBA (for the myriad of things that can't be done in macros) in my database. I even have macros that execute code!

@Pat Hartman is correct that nthere's no real error handling in macros, though -- hit a "bump" and the macro stops cold.

ETA: If you just want VBA, you can create a blank form and put the steps of your macro into the On Open event, then click the "convert macros to code" button. Move the generated code to it's own module and delete the form.

 

[Pat Hartman]

If you know how to write VBA, nothing is easier with a macro.
I don't know of anything that can only be done with a macro but there may be something.

The problem with macros now that they actually have error handling is that they are still difficult to read there is no good tool to print them.

 

[isladogs]

When problem solving databases, the use of embedded macros makes everything much more difficult as the 'code' isn't in a single place.

There are only two good uses for macros that I am aware of:
Autokeys - for creating keyboard shortcuts for certain actions
Autoexec - for startup actions

The actions in an autoexec macro can of course be done in other ways.
However, replacing autokeys with vba is much more difficult ... unless you use Sendkeys which I don't recommend

 

[Cronk]

I'll add some suggestions to that restricted list of macros.



I have one or two macros that I only use for housekeeping ie Relink which then run a procedure to relink between test and production tables.


Another instance where I use macros is where the same control in a form is calling the same procedure. Quicker to multi select the several controls and type the macro name once. The single line macro runs the error trapping procedure.

 

[isladogs]

I'll add some suggestions to that restricted list of macros.

I have one or two macros that I only use for housekeeping ie Relink which then run a procedure to relink between test and production tables.

Another instance where I use macros is where the same control in a form is calling the same procedure. Quicker to multi select the several controls and type the macro name once. The single line macro runs the error trapping procedure.

OK - but both of those examples could be done equally well (possibly better?) using VBA

 

[Cronk]

 but both of those examples could be done equally well (possibly better?) using VBA

In the cases I cited, macros have one line

Run procedureName

The macro is easily accessed on the Navigation Menu for me to execute the vba.


But to each his own.

 

[Pat Hartman]

I do have two macros in every database:
SetWarningsOn
SetWarningsOff

They are macros because:
1. They also turn the hourglass off and on so I have a visual clue regarding the state of the Warnings. Having warnings off is so dangerous that you really need something sufficiently annoying (like the hourglass) that you will turn them back on ASAP.
2. Being a macro makes them easy to execute from the GUI.

 

[isladogs]

Having warnings off is so dangerous that you really need something sufficiently annoying (like the hourglass) that you will turn them back on ASAP

Agreed. So why use SetWarnings at all (even during development)?
Why not just replace completely with CurrentDB.Execute with dbFailOnError

 

[Pat Hartman]

Because sometimes it's just easier to use DoCmd to run a query rather than DAO.