VBA safe?

[Newbie!]

Hi folks

I have been reading own introduction to access programing and I gotta say they sounds rather wary of VBA for security reasons. I can see downloading others databases could be a problem but I'm not quite sure what why they are suggesting your own your database on a server is an issue... unless your code is bad enough it deletes everything!

So is there a reason I should be cautious with VBA?

 

[theDBguy]

Hi. Can you point us to a specific section that gives that impression? Sometime back (a few years ago), there was a worm/virus called Melissa (I think that's how it was spelled). If I remember correctly, it was the first virus using macros or VBA, and it infected a lot of users, because it was unheard of at that time to "be careful" with VBA. Since then, everything has changed regarding views about macros and VBA. Just my 2 cents...

 

[Newbie!]

I have copied below the whole section for context and highlighted the scary parts


"The decision to use macros, VBA, or both depends primarily on how you plan to deploy or distribute the database. For example, if the database is stored on your computer and you are the sole user, and if you are comfortable using VBA code, you might decide to use VBA to perform most of your programming tasks. However, if you intend to share your database with other people by locating it on a file server, you might want to avoid using VBA for security considerations.


You should base your decision to use either macros or VBA code on two concerns: security and the functionality that you want. Security is an issue because VBA can be used to create code that either compromises the security of your data or can harm files on your computer. When you use a database that was created by someone other than yourself, you should enable VBA code only if you know the database comes from a trustworthy source. When you create a database that will be used by other people, you should try to avoid including programming tools that require the user to specifically grant trusted status to the database. General techniques for avoiding the need for users to trust your database come later in this section.


To help ensure the security of your database, you should try to use macros when you can and use VBA programming only for operations that cannot be performed by using macro actions. Furthermore, you should try to use only macro actions that don't require granting trusted status to the database in order to run. Limiting the use of macro actions in this manner lets users to be confident that the database has no programming that could harm the data or other files on their computers."


It sounds more like they don't want users to be scared of the 'security warning messages', though I did hear about viruses and VBA as well from good ol goodle but it seems like these issues where from years ago as well

 

[theDBguy]

I have copied below the whole section for context and highlighted the scary parts


"The decision to use macros, VBA, or both depends primarily on how you plan to deploy or distribute the database. For example, if the database is stored on your computer and you are the sole user, and if you are comfortable using VBA code, you might decide to use VBA to perform most of your programming tasks. However, if you intend to share your database with other people by locating it on a file server, you might want to avoid using VBA for security considerations.


You should base your decision to use either macros or VBA code on two concerns: security and the functionality that you want. Security is an issue because VBA can be used to create code that either compromises the security of your data or can harm files on your computer. When you use a database that was created by someone other than yourself, you should enable VBA code only if you know the database comes from a trustworthy source. When you create a database that will be used by other people, you should try to avoid including programming tools that require the user to specifically grant trusted status to the database. General techniques for avoiding the need for users to trust your database come later in this section.


To help ensure the security of your database, you should try to use macros when you can and use VBA programming only for operations that cannot be performed by using macro actions. Furthermore, you should try to use only macro actions that don't require granting trusted status to the database in order to run. Limiting the use of macro actions in this manner lets users to be confident that the database has no programming that could harm the data or other files on their computers."


It sounds more like they don't want users to be scared of the 'security warning messages', though I did hear about viruses and VBA as well from good ol goodle but it seems like these issues where from years ago as well

Hi. Thanks. I agree with the second red section, but not the first. Macros can be just as dangerous as VBA in some aspects. That's why when you look at the different macro actions, some of them are not available by default, because they are considered "unsafe." You'll have to intentionally display them and use them, just as you would have to intentionally "trust" a VBA project before running it. Cheers!

 

[pbaldy]

I suspect this is a CYA type of thing. Whatever is used to create a program/app, you're putting a certain amount of faith in the author. One that uses VBA is no different. I suspect most everyone here that develops apps for use in a corporate environment uses VBA. It would be difficult to attain the usability we desire without it.

 

[isladogs]

In my opinion, you are misreading the purpose of the article.

Any software can be abused.
Malicious macros can be written. Malicious VBA likewise.
And, of course, SQL injection can be used to wipe data.
For all those reasons, it is wise to be wary of apps from anyone you have no reason to trust

However creating your own apps using vba code is perfectly safe and you can apply security to prevent others from altering that code if that's likely to be an issue

 

[CJ_London]

as a developer I find macro's very restrictive, difficult to debug and impossible to document. For the same reason I don't use the navigation form. So for someone who only wants basic automation and not much of it, then macro's are perhaps a way to go.

However if you are an excel developer, what is called a macro is, in fact, VBA. Interesting that they don't seem to mention vba security considerations for Office here https://docs.microsoft.com/en-us/of...e/concepts/getting-started-with-vba-in-office or here https://docs.microsoft.com/en-us/of...otes-for-microsoft-office-solution-developers

 

[Newbie!]

Thanks folks!

I can now use VBA conscious free


@CJ_London

I'm rather new, but I did get the impression Macros were a restrictive version of macros for the purpose of making their systems more user friendly and... well, stopping people like me doing stupid stuff


Anyway I that’s my query solved, thanks again everyone

 

[CJ_London]

you can still do stupid stuff with (access) macros, just harder to work out where that stupidity is.

You can convert macros to vba - however it tends to be quite inefficient code. Whether that inefficiency exists when the macro is executed I wouldn't like to say. In my very early days of learning vba I did occasionally use macros a bit like a wizard (in excel it would be similar to 'record macro') to generate code. Once I understood the terminology, the functions used and how it worked I could write my own code.