|
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.
|
|
|
|
|
WE don't write forms or code in Acess MDB's, but my company still has applications that use MDB's to store data. We are slowly moving the SQL Express, but sadly the the answer is YES, people still use Access.
|
|
|
|
|
it does seem a mix bag of usage and divided opinions. I knew there would be a large legacy code base, but it does seem that its still very much alive. Like it said in my last post, its time for a survey, but I think it should just be for access not for other DB, so we can get an overall picture.
With so many legacy systems still using it and developers less keen to be, err...'associated' with it , may be it will become a high pay niche sector, I'm thinking cobalt/Fortran/Ada etc
|
|
|
|
|
Access is great for what it does. It's not for heavy lifting. I've used it for desktop apps where I've needed an independent db alongside the app - very handy for such things. You don't need a dba or any support personnel. You don't need installs or upgrades like you do with the big databases. I haven't tested it with lots of data; I know in the old days it was very weak/crash-able when you pushed its limits (eg, 30,000+ records).
|
|
|
|
|
I do lots of heavy lifting with Access and much more than 30k records. also for really large data sets, a SQL back end solves the issues. Then you use passthrough queries to allow the SQL server to do all of the heavy lifting of searching data and handling calculations. It's a great front end.
|
|
|
|
|
I use MS Access on a regular basis, and have been doing so since v2 for Windows. When its limitations are taken into account, it is a useful tool.
Pros:
* portable, a MDB/ACCDB file can be transferred to any PC that has Office Professional loaded. No other setup is required.
* excellent for one-off databases, easy to import data from various sources including Excel or other workbooks.
* easy to use reporting works well for ad-hoc queries and experimentation.
* easy to use for database prototyping, setting up indexes, foreign keys, etc.
* can attach other data sources including Oracle and SQL*Server db.
Cons:
* Doesn't do multi-user well, especially above 5 concurrent users.
* Can be slow with larger record sets (above 100k records). Large databases on a network are VERY slow.
* File can be corrupted (need to compact on close), especially in multi-user environments. [Requires daily backups]
Non-Technical Issues:
* Non-IT professionals build horrendous databases with it. The basics are easy to use but it requires a db savvy person to do more with it.
* IT professionals use Access in situation where "normal" DBMS should have been used, due to the limitations of the platform.
* has a bad reputation, mostly due (IMO) to the last 2 points.
Benefits:
* Works in small office situations that do not have and/or cannot afford a larger db.
* Good for single user and low concurrent user situations, with small datasets.
MS Access is a good tool, in its own arena. Take it out of that arena and you're pounding nails with your pliers ....
|
|
|
|
|
Gotta disagree with a couple of your cons. I build large-scale Access projects. Some have 100's of users. stick all those folks in one front end and yea - Access blows. But I don't know any serious people that do that. I use replicas of the front end. Some choose to deploy separate front ends for each user - what a nightmare. I choose to create replicas upon opening (Open from one location, a copy is created, user is pushed to their copy). All pretty seamless and no one is ever in the same copy at the same time and I don't have to push builds to anyone. Can't say I've never had a corrupted record with this method - but it's rare. Especially if the data is housed in a SQL back end.
With the right developer, Access is really great in a multi-user environment. I've yet to have a project exceed it's limits. The single limitation for me is that it is not web based. That is a major issue more and more. But I also find developers pushing web based tools when the web is not required. It just ends up costing a lot more.
|
|
|
|
|
I had to google 'Access replication'. Cool!
How does Compact work? Same as normal, when the last user logs out?
While I don't currently have a need for a multi-user Access app, I will keep this in my bag of tricks.
Thanks!
|
|
|
|
|
Because their front end is refreshed every single time they open it, when they close one version it's considered dead. So no compacting needed. Imagine a main front end that's 20 MB. The user opens it and a new 20 mb file is created. They use the file all day and it grows to 25mb. They close it. when they re-open the file, they are opening the original 20mb file that was never used, thus their latest version is 20mb.
Then on some regular basis, we keep the back end compacted. Maybe once a month.
|
|
|
|
|
By the way, when I say Replica - I just mean an exact copy of the front end. Not replicated data. Everyone shares one back end set of tables. So the data is not moved around to each person's DB physically.
|
|
|
|
|
Within a single physical file you have: 1. form design tools, 2. a high level, human-like programming language that helps to minimize logical errors, 3. no need to mess around with silly compilers, 4. A complete set of SQL (database) commands for fast storage and retrieval of relational tables.
What more do you want…?
Join the club of anti-curly bracket idiotic coding techniques…
|
|
|
|
|
I've used Access for years to query Access (.MDB), Excel, FoxPro (.DBC; .DBF), SQL Server, Oracle, MySQL and Postgresql databases.
Using the available database drivers, one can query, join, translate, save and / or export data (i.e. ETL) from multiple heterogeneous sources at the same time. For years, the Access "engine" ("Jet") has been used as a database API in VB and VBA for accessing SQL Server databases.
I don't develop apps with it; but do use it to help develop apps; particularly when it comes to data / frequency analysis.
There are technical reasons / restrictions why Access should not be used as a server in a "big database" production environment, but it's not due to any limitations in its abilities; e.g. "ad-hoc" Access reporting is a lot easier than SQL Server Reporting Services, IMO.
|
|
|
|
|
It's beyond totally gross for implementation of anything; especially if you have an object-oriented C# background; such as myself. My version was Visual Basic (shudders). However, I have used MS Access, implemented solutions and it does have some benefits. If you want to use it for a real-time production system; Access isn't a solution for that.
It's best to think of access as a database system for a small number of users; Excel with a better programming/forms interface. I've used it in a corporate setting for some simple multi-team workflow processes to be managed, as part of a development effort. Why not write a Windows form application, etc.? It boiled down to corporate standards; the cost/time to provision a server with all of it's security policy overhead was simply unjustified.
Access, at least in that space, was ubiquitous which means anybody could install/run it, and it was there to fit a need, when filling out email forms was error prone and led to a lot of misunderstandings.
|
|
|
|
|
We will pry MS Access from my boss's cold dead hands. Our major backend processing uses it and we have to adapt our SQL Server processes and tables to it's limitations. Attempts to get him to recode to SQL Server have fallen on deaf ears.
I've always wondered why Microsoft has not put an Access frontend to SQL Server. Drag and Drop query creation is far less intimidating than SQL and you still have the option to edit the Drag and Drop SQL generated.
The Report generator would be nice for SQL Server as well.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
I have been using ACCESS for 20+ years. I have a client whose entire business runs on Access based software and she has had no problems for 18 years except when MS decided to not have backwards compatibility with certain functions or features as it released new versions. I have used it to keep my consulting business client work status and billing records for most of the 20 years. A colleague and I have been using it in as part of a commercial science researcher utilized product (VB for code and Access for the database) for 10 years without any Access problems; VB has given us may more problems as MS changed, dropped, etc. functions, function calls, etc.
I noted at least one commenter stated that is is a terrible product and that a great many terrible applications have been written by bad programmers using it. Well, I have done software quality assurance for JPL/NASA and I can tell you that I've seen terrible programs written in over 20 programming languages and some utilizing a number of databases for back ends. I've seen terrible Oracle and DB2 code. A terrible software architect will design terrible software; and it goes all the way down to the terrible coder creating terrible code. This is not the criteria to use when deciding if some language or database system is the correct one to use for some purpose.
ACCESS is great for simple database applications. It can be used for some rather complex ones also. It depends on the design of the database, the design of the code, the amount of time you are willing to spend learning relational database design and learning to code in Access's programming language. ACCESS is worth taking a look at and getting a decent book is the first step. I've not bought a new ACCESS book since Office 2007, so can't recommend one to you.
Charles Wolfe
C. Wolfe Software Engineering
|
|
|
|
|
I work as a file clerk for a government agency, and I worked with a guy who developed an Access application that parsed reports from our department mainframe into various smaller/localized reports, research tools, and worksheets for use by other clerks in our office. Some of these reports even make it all the way to department managers and HQ.
It's a really handy little thing but he's not a strong programmer and the guy who actually designed it isn't around anymore. I made the mistake of mentioning I had programming skills... and here I am getting caught up in it.
So when you're not able to install real technology, Access can fill the void. But it's painful. If you can convince your IT to let you use real programming tools and database libraries you'd be much better off.
|
|
|
|
|
Was my first database, it's been 3+  years since I last used it.
|
|
|
|
|
Movie Quote Of The Day
I'm a soldier, but in serving my country, I have betrayed my conscience.
which movie?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
