Persuade Client To Convert From Access
-
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.
"Access really sucks"?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
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.
Access does not fully implement the SQL standard leading to awkward query design. This leads to long unproductive hours debugging even basic joins like the left before the right and then the nested parentheses. Without syntax highlighting, it really gets my goat. Translated to user speak; "whatever duration you want the project delivered, please double it."
-
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
So why not move the BE to SQL Server? There may certainly be a business case for that. Stability and speed. In those respects Access, as a database container, is certainly inferior to SQL Server. And then there is the ease of creating SPs using CTEs etc that is way better than the Access Query Builder. But as a tool to build user interfaces, ie forms and reports, for a custom solution it is very cost effective and in the hands of a good developer there are few restrictions. So what is your business case for rewriting their entire application?
-
- Access is buggy. After you've been in the app for an extended period with a lot of objects, the editor stops working correctly, which means you have to exit Access and restart it. 1) Access is not secure. 2) Only one person at a time can have an Access database open for editing at a time. 2) Access is limited in terms of what if can do - Access 2010 specifications - 3) Access[^] 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, 2013I 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 Else '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. Mind you, I have moved on from Access long ago.
-
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.
What you want is "We should rewrite the app" But, they will say, it works! They got a point here, haha... If, for example, all they want is to "add 1 button", then rewriting the whole app for that is overkill... On the other hand if the app is undergoing regularly maintenance and development, how much time will it takes to get the new WPF app is a critical argument. As well as the on going benefit after that, such as better performance, faster developement, easier maintenance (aka less long nagging bug).
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
So why not move the BE to SQL Server? There may certainly be a business case for that. Stability and speed. In those respects Access, as a database container, is certainly inferior to SQL Server. And then there is the ease of creating SPs using CTEs etc that is way better than the Access Query Builder. But as a tool to build user interfaces, ie forms and reports, for a custom solution it is very cost effective and in the hands of a good developer there are few restrictions. So what is your business case for rewriting their entire application?
-
- Access is buggy. After you've been in the app for an extended period with a lot of objects, the editor stops working correctly, which means you have to exit Access and restart it. 1) Access is not secure. 2) Only one person at a time can have an Access database open for editing at a time. 2) Access is limited in terms of what if can do - Access 2010 specifications - 3) Access[^] 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, 20132 is utter BS - I have had pure Access apps successfully support 20 people editing at a time, and Access with a SQL back end supporting 50+ users
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
-
2 is utter BS - I have had pure Access apps successfully support 20 people editing at a time, and Access with a SQL back end supporting 50+ users
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
Chris Quinn wrote:
I have had pure Access apps successfully support 20 people editing at a time, and Access with a SQL back end supporting 50+ users
Ditto!
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Chris Quinn wrote:
I have had pure Access apps successfully support 20 people editing at a time, and Access with a SQL back end supporting 50+ users
Ditto!
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
As I often say in these circumstances, it's not the tool that is used that is usually the problem, but the tool that uses it.
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
-
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 RAH
Access is not single user - based on long experience I would set an upper limit of 15 concurrent users before I would insist on the back end being migrated to SQL server
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
-
2 is utter BS - I have had pure Access apps successfully support 20 people editing at a time, and Access with a SQL back end supporting 50+ users
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
I think he refers to the fact that in the old times access used file locks. If I recall correctly Access is using record locks since 2007. Might be wrong about that though, I try to avoid Access.
Wrong is evil and must be defeated. - Jeff Ello
-
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.
I worked on Access databases for some 12+ years building business applications using Access. The way I would answer the question is that it is not so much that Access itself is an issue, although it certainly has its issues, it's more to do with the quality of person you will be able to hire who is willing to work on Access. There is a bigger pool of experienced developers and DBAs able to support MsSQL and Oracle etc than Access. Access tends to attract the hobbyist(I use the words "tends to" with caution as there will be outliers and some brilliant DBAs and developers using Access). Statistically speaking you have a much higher chance of a decent quality database if the database is one that requires a good understanding of data and databases in order to set it up - Access does not fall into that category. Oracle and MsSQL etc will deter anyone wanting a quick setup - Access actively encourages and attracts users who are completely ignorant of databases and want a 'quick fix'.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Access is not single user - based on long experience I would set an upper limit of 15 concurrent users before I would insist on the back end being migrated to SQL server
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
Chris Quinn wrote:
Access is not single user
I did not know that, it has been 15+ years since I used it. Does it still use page locking instead of record locking?
Never underestimate the power of human stupidity RAH
-
I think he refers to the fact that in the old times access used file locks. If I recall correctly Access is using record locks since 2007. Might be wrong about that though, I try to avoid Access.
Wrong is evil and must be defeated. - Jeff Ello
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. =========================================================
-
Chris Quinn wrote:
Access is not single user
I did not know that, it has been 15+ years since I used it. Does it still use page locking instead of record locking?
Never underestimate the power of human stupidity RAH
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. [RecordLocks Property - Access](https://support.office.com/en-gb/article/recordlocks-property-6ca29bbb-8824-4671-8087-97fe0568019a)
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
-
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. =========================================================
Chris Quinn wrote:
If it appeared to be single user, you had not set it up correctly
That's always the key, isn't it?
Wrong is evil and must be defeated. - Jeff Ello
-
You talking to me? If so, did you even read what I wrote?
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
No sorry Gerry, I was commenting on the original post.
-
John Simmons / outlaw programmer wrote:
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.
To try and provide another side to this. 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. Now this - 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. Continuing Cost -- you are stacked as the most expensive cost and replaced with $100,000 staff. -- Income may still be at $3.4 million.
-
- Access is buggy. After you've been in the app for an extended period with a lot of objects, the editor stops working correctly, which means you have to exit Access and restart it. 1) Access is not secure. 2) Only one person at a time can have an Access database open for editing at a time. 2) Access is limited in terms of what if can do - Access 2010 specifications - 3) Access[^] 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, 2013Depending 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. Also... good luck!
-
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.
Before offering any advice, let's get some details:
- How many users?
- Is the user base distributed, or all on one site and/or network?
- How many tables?
- How many records in the main table(s)?
- How large is the compacted ACCDB?
- How many screens?
- Finally: What is it going to cost to rewrite the application, including on-going maintenance?
As many have stated, Access (like all tools) is appropriate in some venues. It's entirely possible that the application should NOT be rewritten in another technology. The answers to the above questions will help answer the real question: Is a rewrite worth it to the customer? The technology used in any application is far from the most important thing. Focus first on the customer's needs, then their wants, then find a solution.
