I'm playing with Access for a few months now. Still, i have to confes that i a self-learner and i have no idea about VBA. I've tried to get it, but it's to damn complicated for me. Or maybe is not, but noone could explain it for my level. Anyway, i have a question. Lets say that i want to create a app for my cityhall. A app in witch public workers will login (depending on the departament, they will have acces to different forms and reports), will enter date (people adresses, names, other infos), will generete taxes to be paid for a certain year, will record incoms from taxes, and many things specific to a cityhall activity. For such a app (i would like it to be a FE & BE app or, better a webapp) knowing VBA is a must? It's impossible for me to do such a app with only basic knowllege of Access?
Tks
PS: I would like some answers from the users that know what they're talking about. If you've developed a CD collection db, you could state your opinion, but i reserve the right not to take you serioslly.
I'm playing with Access for a few months now. Still, i have to confes that i a self-learner and i have no idea about VBA. I've tried to get it, but it's to damn complicated for me. Or maybe is not, but noone could explain it for my level. Anyway, i have a question. Lets say that i want to create a app for my cityhall. A app in witch public workers will login (depending on the departament, they will have acces to different forms and reports), will enter date (people adresses, names, other infos), will generete taxes to be paid for a certain year, will record incoms from taxes, and many things specific to a cityhall activity. For such a app (i would like it to be a FE & BE app or, better a webapp) knowing VBA is a must? It's impossible for me to do such a app with only basic knowllege of Access?
Tks
PS: I would like some answers from the users that know what they're talking about. If you've developed a CD collection db, you could state your opinion, but i reserve the right not to take you serioslly.
Even people making databases simply for their CD collections use VBA.
That being said, is it necessary? Absolutely not. You can have a fully functional database without using VBA.
However, expect a minimum of functionality, a minimum of security (login forms? nope. Throw them out the window), a minimum of data protection and consistency checks. Webapp? That will require an entirely different set of skills in addition to knowledge of database creation.
You expect to hold private data. Names, addresses, contact information, financials - for a government organization? To be used as a web application? I expect such an application is impossible to competently build with only basic knowledge of MS Access.
Try to find a copy of the Access Cookbook (second edition). It is old, written for A2003, but little has changed with VBA since then. It isn't a syntax manual. It is a learn by example tool. The authors took simple tasks that Access didn't natively do (at the time) and shows you how to do them with VBA. Newer versions of Access actually incorporate some of the functionality described in the cookbook but it is still an excellent, understandable way to learn VBA.
If you want a web app, use A2013 and don't forget, you'll also need SharePoint 2013. Don't even bother with earlier versions. But, before you start, make sure you understand the limitations. No real reports, no OLE automation including no email, no VBA, no Charts, no listviews/treeviews or other ActiveX controls, etc.
No actually. I have always used just VBA but one day I thought I should really get some experience with macros so I decided to make something using them. I built a login form with a password protected button.
It supports multiple users with separate, user-changable passwords.
Sure it would be easy to defeat because the passwords are held in a table and it doesn't have encryption but it works well.
BTW From that experience I learned that macros are incredibly clumsy to work with compared to VBA so I won't be changing over to using macros for anything. Intersting though that the database could be opened without security warnings.
it's hard to be precise, but a lot of VBA programming is defensive. let's say at least 50%
not required to do the job, but prevents users (and even developers) doing silly things when they forget exactly what the dbs does. that's one reason you need vba.
secondly there ARE many things that you must have at least a little vba for.
eg, a form/sub form you can do without vba. single item form, and continuous subform. but if you want both the form and subform to be continuous forms, (often much more useful) then you need to manage it with vba.
It doesn't make sense to me to work with data and have no programming skills. Programming is a tool, like a saw in carpentry, so can you build something out of wood without having to do any cutting? Yes, but you'll be severely limited. Can you write an Access database without VBA? Yes, but you'll be severely limited.
Apart from what has already been said I think learning VBA, or any programming language for that matter, is a good thing because it causes us to focus on the detail of the logic at hand.
The very best thing to test our ability to think correctly is a computer language compiler because the compiler is totally unbiased towards the writer of the code. It does not matter in the slightest who the writer is; the compiler will give totally unbiased advice as to the correctness of what has been written. That sort of unbiased advice is worth a lot of money and yet we get it for free.
I will give an example:-
>>PS: I would like some answers from the users that know what they're talking about. If you've developed a CD collection db, you could state your opinion, but i reserve the right not to take you serioslly.<<
That, to me, is totally ambiguous.
Does it mean that if the person giving you advice happened to be the very best you would reserve the right to not take them seriously if they had also developed a CD collection db? If that is true then you would be reserving the right to not take the very best seriously based on the single fact that they had written a CD collection db.
Maybe what you meant to say was:-
“If you have only ever developed a simple CD collection db, you could state your opinion, but I reserve the right not to take you seriously.”
And if that is true then it leads on to other questions:-
What would you take seriously from someone who has never written any database?
Would you automatically not take them seriously?
And if that is true then it leads on to another question:-
What databases have you written?
If there is no proof of the databases you have written then, I think, we could assume none. While that assumption might be incorrect, we have no proof of anything you have written.
And with no proof of the databases you have written it raises a question:-
Why should we take you seriously?
----------
Now while the above is just personal opinion it is, like the compiler, both free and unbiased. I have no proof of your logical ability with VBA. You have also said:-
>>Still, i have to confes that i a self-learner and i have no idea about VBA.<<
And so:-
If you have no idea about VBA then have you ever posted VBA on this or any other site?
If you can say yes to that then please post a link.
If you say no to that then may I ask a question?
In this thread in post #6:- http://www.access-programmers.co.uk/forums/showthread.php?t=249686
Why did you support a change if you have never used it?
What difference could it make to someone who does not post VBA code?
----------
To get back to the question:-
Is VBA a must? Technically speaking, no.
Is any programming language a must? Technically speaking, no.
But the real value of any programming language is to cause us to focus on the detail of the logic at hand by employing a totally unbiased arbiter to tell us when we are wrong.
And that is worth a lot of money. Do it even if we perceive no reason to do it. Our perceptions may be wrong.
Do you understand the equation Distance = Speed X Time?
OK rhetorical question but I would suggest that everyone who says yes to the above given the right environment can get to grips with the principles of programming. Not just that but I believe that most have already used simple programming without even knowing it. The majority of excel users use simple programming everytime they use the sum function. They even edit the code manually when they alter the formula within the text box.
Its a bit like people speaking English. Children may not know that they are conjugating verbs in the present / future or past tense however they still instinctively can do it. The idea of tense and conjugation is a structure of the language it is possible to speak without knowing that structure but it definitely adds understanding to know the structure.
Understanding programming is like understanding grammar it is the structure with which you already do many of the things that you do.
The trick for me was to fully understand the principle of recursion AND that everything with regard to all forms of programming is based on numbers aka as a variables.
For example - If you replace the idea of a function calculated from a formula of variables with the idea of a variable which itself is calculated from a combination of variables you can see that you are coming back to the simple formula and you see recursion in principle - the calculation of a variable from other variables.
Distance = Speed x Time
Large programs are little more than a collection of functions some complex some simple fired in different orders dependent on the user like one of those books where the user chooses the outcome of the story by choosing options at paths in the story. (You may be too young to remember but there used to be these adventure books that you would read and then it would say if you want to go down the right path turn to page 15 if you want to go down the left path turn to 30) Keeping our book analogy going in access programming the main text of the book and how it looks is handled by the forms and queries of access the what is done on certain actions by the user is determined either by built in functions or something called user defined functions. There is no theoretical difference between the definition of a user defined function and a built in function. Built in functions are just stored "behind the scenes". Therefore understand a user defined function and you will understand simple programming.
As example lets create our own using the Distance formula.
Code:
Public Function Distance(Speed as long, Time as Date) as long
Distance = Speed * Time
End Function
So we know you understand the formula and you've probably clicked that the last line just indicates that the function is over.
Now in any progamming language the central line will almost be identical the symbols can change and users may alter the name of the variables but Distance = Speed * Time is an inviolate physical law.
So all you really have is the ceremony of the First line.
Function indicates you wish to have the ability to calculate a new variable (remember substitute the word variable for function). The computer needs to know what variables are going to be in the formula and what their type are. Public is a VBA convention that indicates you would like to be able to "call" this new function from anywhere in your database.
Thus the variable outside the brackets Distance is defined as type Long
The variables inside the brackets are what will be passed to the computer.
Speed is defined as variable type long
Time is defined as variable type date (date and time stored together in VBA)
So you have now defined a simple Distance function.
Beginners often now get confused with the next section.
But where do I put it? They tend to get lost.
There's two main places you can put it.
1)In a module which is VBA attached to the database
2)In the VBA section with a form
When you create the function Access does a clever thing.
It remembers that whenever you are in that Access database or excel for that matter there's that little bit of code that defines that Distance is speed multiplied by time.
In this way you can "Call" it from anywhere. EG in excel if you were in a cell and you wanted to use the Distance calculation it would be available to you just like any of the other built in functions in excel. And you know how to use the functions in excel don't you!
So going back to Access you could use this function in a query for example you could call the function from a query column which you have built.
Code:
Expr1 : Distance("FieldA","FieldB")
Where FieldA is itself a variable place holder telling the computer to pass FieldA variable into the first variable of the user defined function named Distance and pass the fieldB variable into the second variable of the user defined function distance.
What it returns is itself a variable which you defined as being Distance and which is of a variable type Long.
Complicated or simple functions pretty much all follow this format. You get into clever types of algebra loops and recordsets and you can place functions within function (built in or user defined) so at it's heart its all recursion and its all numbers....
And programming ain't clever - you defined distance so surely it knows how to calculate speed.
No it does not you have to rearrange the subject of the fomula for that and so you would have to rewrite the formula
Computers are fast but they are dumb as a box of rocks.
They really are just electrified plastic and silicon.
The complexity comes from the sheer number of dominoes that align every time anything is done.
Yes it's a must if you need advanced functionality. The learning curve is much smaller than other truly object oriented programming languages .Net or C++.
Hi,
I make my living as a Microsoft Office Access Programmer/Developer(contractor). I've worked for a lot of companies you've probably heard of and I'm currently working for a government sponsored agency which you've probably also heard of. Every one of them asked me right away during the initial interview if I had any VBA experience, as if it were completely normal for a Programmer/Developer to have this skill in his/her toolbox.
So my answer would be, Yes. But not only because I use it for work. The truth is that I'm able to use it for work because I played around with it when making databases for my personal use. I ended up playing around with VBA because I wanted a form or some object to do my bidding and when I googled how to do it, many examples were written in VBA. All I had to do was copy and paste the code and follow instructions for connecting it with my Form in a property. To protect my data, and out of curiosity, I read the script to see if I could understand what it was telling Access to do, then I poked around with it a bit to see if I could modify the "code".
It's funny how a little success in coding will spur the imagination and generate an interest in trying to do more with it. I encourage you to explore the USE of VBA, which you can learn for Free from this forum and others. You may find yourself with another Tool in your Toolbox which could be the beginning of a sweet career, traveling around the country, creating and fixing Microsoft Access databases that mean a lot to the people you end up working for.
The first thing to know is that VBA isn't complex because at its base, it is just the BASIC language - but remember that BASIC is "Beginner's All-purpose Symbolic Instruction Code." (No, that's what it really means.) It was written for beginners.
It is the abilities to look at objects that is complex. If you can do any other language such as PASCAL or C or FORTRAN or {ghack} COBOL, you can do BASIC. The way to understand VBA is to break it down.
It is VISUAL BASIC for APPLICATIONS. The "visual" part means you will be working with objects viewed on a display - i.e. visible.
The BASIC part is just the language.
The APPLICATIONS part is that you will be working with things that are complex because they are part of a complex application.
Let's take simple BASIC:
COLOR = RED
In VBA, objects have colors as properties, so the variable COLOR becomes the PROPERTY of something else. The Access application defines some color constants for you, so let us make it visual:
MyControl.Forecolor = vbRed
Did that get complex? The syntax of the BASIC didn't change. It was the syntax of the operands and the presence of a pre-declared constant that changed.
The reason VBA looks so intractable is that you are looking at the forest and only seeing the trees.
You want to make a line wider? In VBA, the visual object that is a line has a width. BASIC allows you to say
LINEWIDTH = LINEWIDTH + 1
To do this to a visual line, you can use
Line1.Width = Line1.Width + 1
(Yes, you could also do Line1.Length = Line1.Length + 1 to make the line longer, not wider.) Again, BASIC is just BASIC. It is the fact that you are touching a visual object's properties that makes it complex.
May I therefore respectfully suggest the "divide and conquer" method? Learn BASIC syntax if you don't know it already. Then you can do on-line searches for objects in Access by using the great Google-brain on topics like "ACCESS TEXTBOX" or "ACCESS LINE" or "ACCESS CHECKBOX" to see the properties you can diddle with each one. The trick is not that you are using VBA or BASIC or C or VISUAL C or PASCAL. It is that your variables are part of a more complex object that is confusing you, in all probability.
