The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I took on a side project a couple of months ago doing enhancements to an MS Access app. The guy I've been working with has quit. He told me that the company wants to continue using me. I think I'll be working one on one with the owner.
So, I see this as an opportunity to move them from Access to .Net. If they do it will most likely become a WPF app.
What I need is persuasive information. Just saying "Access sucks" won't do it. So, how would you approach this? What arguments can you give to help them decide to move to .Net?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
Here are the reasons I dislike access and agree with the OP.
1. Flaky on large scale deployments. We have experienced random issues when going over 4 users.
2. You always add in some code so you have to adjust the trust settings. So every time you deploy to a new user you have to go manually adjust their trust settings.
3. Most of the users set the trust setting to enable all macros. This creates security issues.
4. Instead of using a weblink (unless the OP was talking about a native application) you have to set up shared drives (yes I know that you can do webpages too but....). You can do that with a logon script etc, but again, added manual intervention.
5. Kicking people out of the database every time you want to make a change, no matter what it is.
I think there's more, but those are the major ones for me.
4) Access is not intended to be used as an enterprise database solution.
5) Finding skilled Access developers is becoming more difficult as time goes by because the money is in SQL Server.
6) Access sucks.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
Finding skilled Access developers is becoming more difficult as time goes by because the money is in SQL Server.
That should be enough reason IMO. Finding people willing to work with Access is only going to get more and more difficult, which means the longer they wait to transition to something else, the more expensive that transition will get in the long run.
From a business view - Hiring Staff becomes more expensive due to the tools (access) being used, vs retraining AND/OR changing out processes (the scripts and stuff built with Access) to a different set of systems which has lower staff costs
Keep Access -
- maintenance costs - unclear
- staff costs - replacement expensive and retaining strong staff difficult due to possibly they want to learn new stuff
Change it (.net)
- rebuild cost -
- staff costs - lower - better supply vs demand then Access
- maintenance costs - possibly lower - due (hopffully) having a larger set of requirement from the start to build for. Where the access might have years of built upon patches.
- if using the Access brings in say $3 Million a year
- and has a staff cost of $500,000
And the Rebuild
- Build Cost - 500,000
-- takes 1 year to get up to matching speed
-- no new updates to the Access during this time.
-- you are stacked as the most expensive cost and replaced with $100,000 staff.
-- Income may still be at $3.4 million.
I would argue 2 is incorrect. Access can be multiuser, but you have to implement it properly.
You need a central error handler that retries particular classes of errors
If (ErrorNum < 3000 Or ErrorNum > 4000) AND ErrorNum <> 2448 Then
'Process As Error
'Retry up to 60 times
(60 times for the same error no) before presenting any error to the user.
Also you need the code and data mdbs seperated into different databases.
This works like a charm for multi-user.
I have worked with Access since v2 and it has never been single user if set up correctly. It always creates a locking file (ldb in earlier versions, laccdb in later versions) to keep track of multiple users.
If it appeared to be single user, you had not set it up correctly. Splitting the system into front and back ends, with the back end on a proper network share, and each user having a local copy of the front end was always the way to go and worked well (and presumably still does - I'm a SQL DBA now) , so long as you were aware of its limitations.
As I said earlier, if you were looking to more than 15 concurrent users, pure Access is not the way to go, but it can still be used successfully to front-end a SQL databases.
I rewrote and maintained a 50+ user order processing database for a previous employer that has Access front end to SQL back end over 10 years ago and I discovered recently that it is still in use and still working fine, handling several million pounds of orders per year.
I'm an optoholic - my glass is always half full of vodka.
Depending on how the front end is implemented, it is all too easy to delete vast chunks of data that suddenly become unrecoverable. An Access front end (used to) automatically carry out database operations such as delete without any logic.
I had a customer hit Ctrl+A then delete and wipe out most of their billing data as the data on screen was pulled from a table rather than a view. It took about 4 weeks to recover most of their data. Understandably they weren't hugely happy with this, but the application was built fairly badly (before either my predecessor or I got our hands on the code.)
The app was multi user with an MDB back end and an MDX (Access executable) front end. This kept the code hidden from the customer, but also meant we had to implement releases to update it.
So - if the GUI hasn't been implemented properly then you may be just as quick building a new front end with the correct logic layer, and a suite of APIs in the background.
In addition to what John said.
Access is single user - MS has documentation stating the fact somewhere. This should be the single most compelling argument to change to an n# tiered solution.
Access is an OFFICE tool - that argument should kill all further discussions. I don't know the recent history of MS Office upgrades but in the 90s every upgrade would break the applications I had written in Access. Moving to SQL Server eliminated that horror.
Oh yeah and Access sucks!
Never underestimate the power of human stupidity
I'm not sure of the latest versions, but I think record locking has been implemented - I've not done any Access development for about 6 years (though I still use some databases I created back then for personal use.
Access is designed to have up to 255 simultaneous readers. It supports about 5 simultaneous writers. Access 2016 runs Access 2010 code with no changes.
Interesting tidbit about MS-Access - Access 95 and 97 actually implemented more of E.F.Codd's relational database rules than Oracle and Sybase.
Access sucks in the wrong environment. In the right environment and with a proper problem domain Access is the right tool. No, I wouldn't use it for a medium or large database project with multiple users but for a single user tracking a small number of items it works great. You can even connect to it via the OleDatabase classes in the dotNet framework.
The assumption (overall) seems to be that Access is being used to "build" business apps.
The fact is, it's quite reasonable as a "user" tool for querying "back-end" "big" database systems like SQL Server, Oracle, MySQl, etc. For ad-hoc queries, Access is much simpler than SQL Management Studio, BI, and the like.
It can be used to analyze practically any data source including Access, Excel, CSV, SQL Server, Oracle, DBFs, ... and "join" them.
A knee-jerk rejection of Access is short-sighted ... particularly when it comes to "another quicky report request" that any thinking user could handle.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
Last Visit: 31-Dec-99 19:00 Last Update: 24-Nov-17 14:57