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.
Shirley there is enough technical debt and a cetain lack of maintainability that can only be cured with a little architecture?
I have lived with several Zen masters - all of them were cats.
-
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 in Access is giving problems? Why do you want to trash Access, Answer that question and you'll know what to present. If you can't answer it, maybe you should keep Access.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
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 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, 2013 -
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.
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 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, 2013John 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.
-
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.
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
-
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.
Mildly confused here. I have written several .Net applications which suck their data from Access, because that's what the client wanted. Up to half a dozen users is fine, as long as it's on a decent piece of iron. I do draw the line at VBA, though, as that is an anathema to a sensitive soul. The only downside is, as JSOP pointed out, security beyond a fairly trivial level. Also, it is very little effort to upgrade the database itself to SQLserver, using the MS tools provided.
-
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
