|
MS stopped making improvements in Access with the 2003 version. But - they have improved Access for power users since then.
It doesn't make sense for MS to put resources into improving two products for the same set of developers. The IDE in VS is much better than the IDE in Access.
|
|
|
|
|
Access is great for manipulating data from one format to another, outside of that I have not used it
|
|
|
|
|
I also used MSAccess for back-end DB while ago..
But now I'm using LocalDB or sometimes SQLite... 
Don't watch the clock;
Do what it does.
Keep going.....
|
|
|
|
|
Many years ago but I don't want to see it again - ever.
However, I'd gladly go with dBase III and Clipper again.
|
|
|
|
|
I loved Clipper - you could link c modules to it which was way cool at the time.
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Access is a true RAD tool. If you can model data and build SQL Express databases it is perfect. The query builder and reporting is the best in the business. One day, building web databases will use the same techniques to build views as access uses to build forms. (instead of typing in a morass of HTML).
Most of the comments here are simply wrong - its a great tool and Microsoft has made (yet another) mistake in not developing it further.
Ray Starkey
ACCESSible IT Limited
Coventry, UK
|
|
|
|
|
I fully agree with you. MS Access is a very good RAD tool and perfectly fine for smaller, tactical solutions. To throw the entire technology stack at a problem isn't always wise 
We use it in our company for various purposes.The entry level is relatively low and that maybe explains the image MS Access has. Everybody can crank something out in relative no time but in the wrong hands, the best tool can be disastrous!
When we decide MS Access is good enough for the task to solve, we still apply IT best practice in designing, programming, testing etc. We don't have many of those application but they do what they are supposed to do since years very successfully and reliable.
Cheers
Rene
Working at a larger Reinsurance Company
|
|
|
|
|
True about reports. When I'm making a report in VS I wish it was as easy as it is in Access!
|
|
|
|
|
It can make a very fast way to play with data with it's import abilities. Last time I used it was for facing a SQL database table in about 20 minutes start to finish - try that with anything else in that time frame 2 years ago.
|
|
|
|
|
I use it for analyzing millions of records from web server logs with SQL queries about once a quarter.
Easy to import the logs, simple to write and apply custom functions for massaging column data.
Copy+Paste results into Outlook or Excel.
Easy to throw away when you are done! Just purge the table containing the log records and retain the queries and custom functions.
|
|
|
|
|
You can hook Access to almost any type of database file. Easily write queries and easily make good reports. This is a great way to use Access!
|
|
|
|
|
There are a ton of apps we dark matter developers need to mantain that are too massive in scale to port to other runtimes. (wheter it be because of scale of the project or because you have a dinosaur boss in the way (such as my case))
I for example, mantain a manufacturing support application that uses access, and for what is worth, it does processing crap really fast with an sql server back end. Too bad it doesn't support sql batch statements or better vb data structures.
|
|
|
|
|
Yes, and Access can work quite well in small office settings. Many things work very well, but it also does have downsides (particularly handling memo fields). It you need a lot of control over keyed inputs for forms, etc., it is going to be more difficult to accomplish with access as a front-end, but most items can be done fairly quickly and work quite well.
|
|
|
|
|
I am a developer of business applications with MS Access version (97) for small businesses and professional firms. Develop programs with MsAccess is a guaranteed investment over time. The programs were converted in later versions of MsAccess (2000/2003/2010/2013) with SO Xp. Win 7, Win 8 and finally with Win 10. Queries, Forms, Reports and VBA are more than enough to satisfy monoutenze and multiuser with 10 users. With accesshosting.com also work remotely.
|
|
|
|
|
Yup. I made over $200k last year developing in MS Access. And in ever case, it was just the right tool.
If you are good at it, it's a great product. Not without flaws like every tool, and limiting compared to some, of course. But if used in the right situation by someone that knows what they are doing, it's simply a great tool.
I build complex applications that save tremendous amounts of time. Multi user environments are just fine. Lots of data. Lots of calculations and automation.
Like anything, it sucks in the wrong hands.
|
|
|
|
|
You will find that MS Access is used widely in banks and trading companies. They use it because it is a great tool, along with Excel for modelling and reporting data sets from a wide range of sources such as SAP, Endur, Reuters, Bloomberg, Oracle, SQL Server and so on.
Up-to Access 2010 Microsoft had a great feature where you could remove the Jet database engine and replace it with SQL Server (this was called Microsoft Access Project). This would provide you with the enterprise features, security and scalability, of SQL Server with forms and reports built in. I use this feature a lot. My current project at a global trading firm is for a price risk tool that is used globally with 200+ users, hundreds of millions of records and is used to make mulit-million dollar decisions.
The forms and reports editor in Access is still a league ahead of the clunky tools available in .NET for desktop applications, although Access does lack all the fancy 3rd party add-in's you can get for .NET. Unfortunately Microsoft has neglected the tool over the years and the last good version of the tool was MS Access 2010.
I know VBA gets a bad rap as a programming language as there are a lot of bad Access databases out there but it is actually quite powerful when used correctly. You can write bad applications in any language - i have seen enough poorly written C# applications over the years.
Also the best thing about MS Access development is the pay - it is at least 50-100% higher then the top rated day rates you can get with any other programming tool available. You do need to have a trading background though to understand the models - it is that knowledge you are getting paid for, rather then your skill with VBA
|
|
|
|
|
Good to here for everyone, sounds like its still very much alive and I didn't know, which is why I asked the question.
I was always led to believe that access was 'evil' and something for hobby use only, So I never got involved.
Your right, you can use any language to write bad code/projects.
I think its time we had a survey!! Top 10? but which ones, I'm sure this will divide the community, and possible the world 
|
|
|
|
|
YES, I use MS-Access.
There is no other choice if you need a multi-user database shared over a network, and you can not install SQL Server or any other database server.
And you cannot achieve this with SQLite or SqlServer Compact Edition.
___
|
|
|
|
|
Yes, it is used... actually quite a bit. Generally, not by developers, but by users.
It is used in commercial software (e.g. gINT)
Should you use it? Probably not.
Should gINT use it? Probably not.
When should you use it? If you have to give a database to a non-programmer who has Access installed on their machine or some other rare use case where is makes sense.
I've actually use (yes present tense) an Access front end to process some SQLite files and it does what I need no fuss no muss.
|
|
|
|
|
I have seen in use by businesses that have poor IT skills and got sold incredibly expensive applications biult with Access.
Please, DON'T use it or recommend it. There are lots of free tools that do much more and are better supported.
|
|
|
|
|
carlospc1970 wrote: have poor IT skills
.. key phrase.
Like anything when abused.
|
|
|
|
|
We're still using it, although after the best part of a year of inexplicable crashes and corruption errors we're in the process of replacing our main database for another one. There's still loads of cheap crappy databases floating about though (some of which are now also developing random bugs even though the source code hasn't changed in months.)
I'd agree with others that it has its place, but its place isn't in a corporate environment. As a rule, it only ever seems to be used in a multi-user setting out of either necessity or cost. Avoid in all other cases.
|
|
|
|
|
I think most issues with Access come from inexperienced developers and a fussy user base. It's easy enough to build some simple things in Access and so people with limited knowledge think they can build high level tools. Those people are dangerous. Again - the problem is with who is developing, not the tool itself. If you know what Access is and you know how to design a proper UI and database, as well as code, then there is nothing that can match the ease and cost efficiency.
I make a living at Access development and I have hundreds of applications in use. Many mutli-user environments. Many with massive amounts of data (though the bigger data sets use a SQL back end), and my user base is happy as can be.
I can do more in .net, obviously, but the infrastructure is much more expensive. If you have an application that does not need to be online (forms-wise), Access is the cheapest, fastest way to go. And in the right hands, at least as powerful. People should stop blaming Access for the crappy skills of many of the people that try to develop in it.
|
|
|
|
|
Member 11273627 wrote: People should stop blaming Access for the crappy skills
Indeed!
|
|
|
|
|
Wow - there is a lot of animus directed toward MS Access.
I wonder how many people actual actively use it or are just haters....
Just some background - my company develops applications using LAMP, SQLServer, SQLite, and Dot.Net connectors to many other databases - so I think I'm fairly agnostic. A couple years ago, we needed a simple input form to capture some information quickly and I had something up and running in 30 minutes that worked just fine in Access - no server, no program, no debugging. Below are my thoughts about MS Access.
MS Access is a number of things in one package and it might *just* be able to help you out.
1. It is its own proprietary database and has its own SQL Syntax (and query builder)
2. It is stand-alone file, much like SQLite
3. It handles multiple connections to a single database file over a network share pretty well.
4. It has its own JET engine to allow other programs to connect to it (I think it has a DotNet connector now as well)
5. It has its own reporting engine built in to the program
6. You can quickly and easily develop an extensive GUI to edit and access your data.
7. You can embed reports, GUI, and database into a deliverable, protected file.
8. You can write things that are usually tough for databases to do (iterations over many records) in the included VB scripting language.
9. You can develop a front end and reports in MS Access and connect to pretty much any ODBC compliant database in the backend.
10. You don't need (or need to be) a database guy to use it.
11. You will not notice (unless you have millions of records) any issues with the DB engine in terms of speed.
There are some DISADVANTAGES to MS Access, but they are not due to the program. Because it is so easy to develop a pretty involved database and application in MS Access, non-DB types will often build what they need. This often leads to the following problem flow.
a. Database tables are often just thought about just like excel files.
b. This leads to *lots* of non-normalized data
c. After a couple (or ten) years, someone will hit a wall where they get stuck and can't figure out how to do something in Access.
d. At which time a "real" DB guy will be brought in to help figure out how to get things done.
Be careful here, because there are three options that can arise at this point.
e1. If this DB Guy is a DB admin, he will find that he can import the data easily into SQLServer. However, at this point he is basically screwed. In my experience, there is no way to easily replicate the ease of building a GUI in SQLServer, MySQL or elsewhere.
e2. If this DB Guy actually *understands* the MS Access Paradigm (most devs WILL NOT!!) he may be able to write a few lines of complex VBA code to add your new features and you can happily keep on using MS Access.
e3. If this DB Guy is a standard developer, first he will suffer from massive brain hemorrhaging trying to figure out what was done in the MDB file. Then he will suggest moving the ENTIRE system to his favorite environment (MySQL/SQLServer/PostgreSQL and PHP/Rails/DotNet/Entity) usually at a huge cost to the end user.
We have been the recipient of a number of large projects because of the flow above in the e3 iem above - the MS Access app just got too big and what was needed was a large enterprise level web-based application. But in one case, we were able to just put a PHP-Based Website up that used the existing MSAccess database and the customer was pleased as punch. And in another, we took an existing MS Access database application and migrated it to have a Windows front end, but kept the MS Access backend.
My MSAccess developer information is old (circa version 2003). but my guess is not much has changed in the subsequent versions except the UI got less intuitive with the introduction of the ribbon.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
