Is any one using MS Access?
-
ACCESS is so good that MS is killing it because is a big competitor of VS. ACCESS is the fastest RAD tool and you can do petty good desktop and web applications for SME or departments almost without code. Access it is simply fantastic. And of course there are millions of people using ACCESS.
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.
-
Just updated office 365 and along with it Access 2016. I've never used it. Does anyone use it? What for? and should I?
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 ea
-
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 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.
-
No they are not - a MDB of ours edited with 2003 is no more usable on our machines. Something, somewhere, breaks. We'll fix when we'll change logging operations (it's in the TODO). Consider that there are 3 tables with no relation between them - it's fugly but that was what the best heads could come up to 15 years ago.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
-
Power users can make good use of Access if they limit themselves to what they know, and they don't try to make it a multi-user application.
DanW52 wrote:
Power users
Never, ever, give power to a user. Nothing good can result.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
-
Just updated office 365 and along with it Access 2016. I've never used it. Does anyone use it? What for? and should I?
-
Just updated office 365 and along with it Access 2016. I've never used it. Does anyone use it? What for? and should I?
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 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.
-
I've made four highly multi-user applications with Access, three now in use at manufacturing companies. The multi-user part is a challenge. I set these up so that each user gets their own appplication file on their client PC connected to the data file on the server. I've also made an auto-updater file that automatically updates the client PC with the latest files each time the user logs in.
Same here. I have an Access based application running my company for 18 years. I think it's ok up to 25 users. If we needed more users I would consider a back end based in SQL Server or Maria DB, but the front end is ok to make quick forms an reports. Our database is 800Mb and keeps tables with way more of 100k records. Just don't keep LBOs there, try a workaround and everything will be fine. If I started today I would choose another database engine. But then again, Access is taking care here of an aplication that involves invoicing, suply chain management, payrolls, bookkeeping, Document management, and some sophisticated functions like geolocation, web content management.. .etc
-
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.
-
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
-
No they are not - a MDB of ours edited with 2003 is no more usable on our machines. Something, somewhere, breaks. We'll fix when we'll change logging operations (it's in the TODO). Consider that there are 3 tables with no relation between them - it's fugly but that was what the best heads could come up to 15 years ago.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver "When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
An .mdb file is compatible with Access 2002/2003/2007/2010 - I only use .mdb files. If it's breaking it's probably a conversion issue, not compatibility. Instead of converting, try copying and pasting the data. Or, upload the data to SQL Server (Express) and then use a make-table query to bring it back to a newly created Access .mdb file.
-
Professionally I use SQL Express, LocalDB and MySQL and couldn't think of any reason to use Access. Just though it was a hang over from another era, and looking at the comments, looks like it is. So why is it still shipped? MS has dropped other technologies over the years? I guess it still has a large user base
I think that about all I use Access for anymore is the "documenter". I use SQL Server but access has a neat and concise way to print off details of the tables that I haven't found anywhere in the stock SQL Management utility.
-
Just updated office 365 and along with it Access 2016. I've never used it. Does anyone use it? What for? and should I?
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 ....
-
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 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.
-
Professionally I use SQL Express, LocalDB and MySQL and couldn't think of any reason to use Access. Just though it was a hang over from another era, and looking at the comments, looks like it is. So why is it still shipped? MS has dropped other technologies over the years? I guess it still has a large user base
Access is part of about 90% of my development projects. Usually as a RAD front end to MySQL, PostgresSQL, Oracle, SQL Server, and sometimes more than one at the same time. How many dev tools do you know that can connect to SQL Server, MySQL and Oracle at the same time? The ACE DB Engine is really only good for apps with tables less than 100K records, or so, but Access makes a great desktop front-end. Access != ACE (Access <> ACE for the VB fans). Yes, it's best use is for desktop apps connected to shared data for 20 or less people (up to 50 with a RDBMS back-end). The Sharepoint/web integration is basically hell, since you can only use macros (no VBA). Using macros is like trying to build a house when the only tool you have is a bag of sporks. Although, the new JavaScript integration in 2016 may help change that. As I've grown as a coder, it took me a while to understand certain concepts that are now must have features in modern languages/ide's: Managed Code, VBA in Access has always been managed. Lambda Expressions, oh, you mean you can just create a function and call it from anywhere? You know, like a function in an Access module rather than class. Binding fields in a table to controls on a form is ridiculously easy (built-in sanitizing, character limits that match the field, data-types, a plethora of events to add validations, etc.). Don't worry if this frightens you, its lack of layers scares many. But, then again, you may not want to listen to me as I am a wildling coder. After some excellent instruction in high school, I did not go the the ivory towers and have spent most of my career on the other side of the wall between IT and everyone else... solving problems as quickly and efficiently as I can, with only the tools I have available to me.
"But then, something happened that the ring did not intend." - Fellowship of the Ring
-
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.
-
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!