Building a DB: When to use VBA Code and when to rely on Access-Functionality

[FinisherProgrammer21]

Hello all,

my situation is the following: I conceptualized a Database for a certain process of a company.
Basically, the workflow that is to be implemented is:
1) Create users


2) Select an intended qualification which consists of two aspects
3) Insert evidence of the user for the approval of the intended qualification
4) Select necessary criteria that are needed now based on the selected intended qualification (depending on the special intended qualification aspects, there are different criteria that are now relevant: this is some regulatory stuff that is given).
The now relevant necessary criteria (these are questions) are to be assigned to a specific user.
This combination of criteria and user is to be evaluated (passed/not passed) based on the evidence that is given in Step 3. My idea is to implement an automation that inserts this combination of criteria and user (called question in tbl_question) is now connected/concatenated with the evidence the user has submitted in step 3 (a table called tbl_QuestionEvidence) and stored.

I have also implemented a Mockup without any functionality but only to have an orientation for the interface of the DB that is to be developed.
My question is: Since I am a newbie in Access and VBA, when do I need to implement code and how can I find out if I can also use some functionalities in Access itself. Because it is quite hard for me to figure out what Access can do "automatically" and when code is mandatory. Because I want to go the most-easiest way of course in order to build the DB as quickly as possible but with some certain automation features such as buttons (e.g. do I only need Code for Event-procedures such as Drop-Down-Menus or Buttons?).

Do you guys also have other tips how to implement a Database that is already conceptualized (model is approved, workflow is approved, requirements are approved).

Greetings,

FinisherProgrammer21

[ranman256]

you should be able to do 99% in access using queries,macros.
sometimes there are moments where vb works better.

[CJ_London]

you can use access wizards to create forms, provide functionality behind buttons etc. But the designs are functional at best - you won't be getting any 'wow!' awards and generally not very efficient for larger databases. And down the line you will need to use vba to provide functionality the wizards and macro's can't do (a login form springs to mind). Wizards will create macro's which, providing you have provided the right information will work. But if it doesn't it can't be debugged, there's no facility for documentation and any error messages are not necessarily very helpful. Most developers avoid them because of this. Note that access macro's are different from excel macro's - which are actually vba. With Access macro's you select from a relatively limited list of possible actions - although I guess the list is comprehensive enough for most applications.

If you are developing this app, things will change from what has been ordained, either because you are limiting yourself to wizards or the 'if it can do this, can it do that?' scenario to relatively simple requirements around changing the way the form is laid out. Do you really want to have responsibility for an application where you don't really know how it works?

Things you haven't mentioned but are critical to the design of the app

how many users there will be - app should be split anyway for ease of maintenance but leads on to other questions
where are your users when they use the app? All in the office on a wired? wireless network?, working from home? mixture of both? required to work at a client/supplier or whilst travelling?
data volumes?
what types of devices are they using - design forms for the smallest screen
what data security plan is required - protecting what?, from whom?, from doing what?

You've made a good start - you should have your table design and relationships ready to go. One tip, don't include spaces or non alpha numeric characters in table and field names and don't start them with a number.

[FinisherProgrammer21]

thank you for your advices! I will consider that!