Someone I met told me that MS Access and VBA are obsolete!! (1 Viewer)

[AccessPractice]

Hi
Today I sat and learned MS Access focusing on VBA at Starbucks.A man who works as a programmer stared at me and said to me that I shouldn't use Access to create a database because it is obsolete.

And he suggested I should use ruby language with sublime editor combined with mySQL or PostgreSQL and write onto the web by HTML JavaScript.

He also gave reasons that his approach is much more universal such that it can produce on many devices i.e. iPhone, Android, on Windows and Mac, has better user-interface and can upsize the database to much more than Access can do.

By the end of his words, my mood went down and I thought whether I was wasting my time learning Access and VBA. I have been self-studied for almost a year!!

What is your opinion?
Do I have to change my mind?
Thank you

 

[jdraw]

Did he ask you about the application you were considering, or the business issue you are trying to support with a database?

 

[sneuberg]

Even if Access were obsolete learning it and VBA wouldn't have been a waste of time. Some skills would carry over to Web-MYSQL environment.

 

[pbaldy]

Access is a tool. Like any tool, it is good for some tasks and not good for others. A blanket statement like that is ludicrous.

 

[CJ_London]

I make a (very) good living developing in Access, but also use other languages as well. As jdraw says, it all depends on the application requirements and the budget.

You can develop stuff in Access in a 10th of the time it takes in other languages so if budget is an issue, access is the way to go. About 3 years ago I wrote an app for a national utilities company to address a critical issue. The IT department sneered at the fact it was written in Access and said it should have been written in .net with a sql server backend - and then quoted around £500k to provide the solution - guess what, 3 years later my app is still in use. It didn't need to be accessible by 5000 users from 100 different types of devices, just 5 or 6 users from their pc's or laptops in the office - and saves the company around £1m/year.

If you need an app the general public can use from laptop/phone pc or mac then access is probably not the right development tool, but within a corporate environment, you can use terminal server or citrix - which if set up correctly can be accessed from laptop/phone pc or mac.

With regard upsizing, access is in two parts - a front end and a backend. The backend can be anything - access jet/ace, sql server, oracle/MySQL, take your pick. And providing each user has there own front end (in the same way they have their own excel app or browser) then number of concurrent users is limited by the backend. And you can utilize server side processing to help maintain performance.

Your companion mentions javascript. It has been phased out in Microsoft Edge (replacement for internet explorer) and I believe is to be phased out of Chrome, which basically leaves Firefox. So as far as access via a browser is concerned I think (my personal view) only thing worth considering and keeping up with is HTML5 - and be aware it changes frequently - what worked last month won't necessarily work next month.

As snueberg says - learning access/vba gives you a good grounding for moving on to other languages (I found it particularly easy to jump to C# and Java) although nothing beats Access for ease of form and report creation.

All depends on the direction you want to go - simplistically the choices are at one extreme tactical where Access sits (needed now, easy to modify and adapt to changing environment) or at the other strategic (needed within 3 years, generally fixed in design/purpose from outset) - although there are plenty of flavours in between these two extremes.

 

[Ranman256]

they still work great.

 

[gemma-the-husky]

Seriously if you don't use access, you've got a hell of a development issue building the interface elements that access gives you.

 

[Lightwave]

People want to be using tools in their sweet spot and his tools have a completely different sweet spot from MS Access.

The lad is talking about developing dumb applications for general public in which case he is not totally wrong. BUT he is FAR FAR from right. Access is the leader in small high value super complicated database form driven applications with manual input.

Do you know how many applications that covers?

Literally millions for which there is NO market alternative.

I have yet to be presented with evidence that shows a tool that will allow you a quicker or cheaper way of developing tools for 1 to 50 people and once you get better will easily cope with 100s of people.

Honestly disrespecting other peoples systems and methods is usually a mixture of paranoia, ignorance and arrogance.

I like cycling
I have a mountain bike
A race road bike
A winter road bike
Commuting bike

I would have a complete headache if I used just one for everything.

 

[The_Doc_Man]

Maybe that person was speaking of a narrow environment. In particular, if he was talking "web-based" then maybe he was right. But if you were thinking "in-house network with no public web exposure" then he was a narrow-thinking fool who can see the trees but cannot see the forest.

Access has incredible versatility. It can go from a personal/private database app to a perfect tool for small business development. Anything you can design in Access can be grown to larger systems very well - and if there is an ODBC driver available for the larger systems, you can CONTINUE to use Access even if the database gets too big for normal use of Access's Jet or Ace engines.

If you see that person again, you have my permission to pour hot coffee on his crotch.

 

[kevlray]

People want to be using tools in their sweet spot and his tools have a completely different sweet spot from MS Access.

The lad is talking about developing dumb applications for general public in which case he is not totally wrong. BUT he is FAR FAR from right. Access is the leader in small high value super complicated database form driven applications with manual input.

Do you know how many applications that covers?

Literally millions for which there is NO market alternative.

I have yet to be presented with evidence that shows a tool that will allow you a quicker or cheaper way of developing tools for 1 to 50 people and once you get better will easily cope with 100s of people.

Honestly disrespecting other peoples systems and methods is usually a mixture of paranoia, ignorance and arrogance.

I like cycling
I have a mountain bike
A race road bike
A winter road bike
Commuting bike

I would have a complete headache if I used just one for everything.

I like cycling and have one bike. It works good for most cases, but not all. Thus Access and VBA have a place and do a very good job where it is best suited for. But there are other tools that work much better for other situations.

 

[gemma-the-husky]

Another point.

Access is, or ought to be, as obsolete as excel.

For many projects that people manage with excel, access is a better solution. It's just that most people don't have the skill level that access requires.

 

[The_Doc_Man]

The more I think about it, the more I have to ask the question: Define "obsolete" please.

If we are talking about a method that involves writing web-based code and SQL-based processes and then comparing it to Access which involves interactive GUI functions and SQL-based processes, we are either talking about two peas from the same pod (you write code for an interface and SQL for backend processing) or we are talking about two totally different animals (web-based GUI vs. interactive-session GUI) with HTTP/HTTPS protocols or SSH/TLS/{gasp}TELNET protocols.

Access will become obsolete when we can plug something into a socket in our heads and THINK the questions, designs, data, and images to the computer, which will then translate them automatically.

If you have something that "reads" text via scanner, either web-based or TLS-based GUIs would be able to use that; it's just a file. If you are recording images for display, either method works. Access and web code both support images, multi-media actions, data changes (with appropriate code libraries to back you up in your efforts), ... you get the point.

It is philosophically wrong to say that Access is obsolete until you can point to what will be its functionally equivalent replacement, and it has to exist to the point that it can be publicly demonstrated, not just at the pipe-dream stage.

The reference to Web technology being better is a lie (because the question is ill-formed). Web technology is better when in an environment for which web methods exist. If you still have to design your own web pages and key in a bunch of text and specify a bunch of controls (even from a GUI-based design screen), you aren't doing anything different in general concept from Access. You are only doing something very different in low-level details. But just because two things are different doesn't mean that they aren't equally useful in proper context. (Sorry 'bout the double negative...)

 

[Simon_MT]

I was reading a manual on SQL Server and they suggested reporting Excel and a forum suggesting SSRS is a new technology and SSRS should be used. Having written VB for web sites I would have been flummoxed without the knowledge of VBA. I believe sharepoint does not support VBA - big shame. But to use Excel for reporting I believe there are better reporting tools. I will say that Products like Power BI have there place to highlight trends, variances and ratios but with the new hi-res screens you put more information on a screen than a report so there is nothing to stop using Access to Report to screen.

Simon

 

[The_Doc_Man]

Even the biggest DB Bully on the planet, ORACLE, has to use a package called ORACLE Tools if you want to do reports in the same general way that Access does them. Otherwise, your report is a tabular thing that looks spread-sheetish.

 

[dan-cat]

Time spent learning a particular platform is never wasted if you do it right.

However do take some time to consider whether you will ever want to investigate the fields he is talking about.

Are you interested in consuming Twitter/Facebook/Google APIs?
Will you want to build a Mobile App that uses a common database?
As doc says, will you want to be able to fulfill a client's request to expose their access db to the web (share product info, take public orders etc etc.)

If you see yourself wanting to do these things in the future, then yes, reconsider.