Persuade Client To Convert From Access
-
- 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.
-
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 Suck!!! I have been a .Net stack developer since .Net came out and vb, pascal, cobol, even cold fusion, java, etc. before that. Its more about the right tool for the job. Done right ACCESS is totally awesome, but it does have its limits. Like 2GB table size. 25 max simultaneous users. With the right size computers, yes it will support 25 users and record level locking. You just can't argue to move to SQL and .NET platform without first defining the project. Regardless of perception, SQL and .NET will cost more to support in the long run. Access done right should not cost anything unless development is on going. Maintenance should be a function of the way it was designed, that is to say old data purged at some point. If it can not be for whatever reason, that may be an argument to step up to SQL. But you could still use Access as the front end and just link to the SQL tables. Lots to consider, good luck.
-
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?
I agree with you a 100%. Even if the customer cannot afford to buy the full fledged MS SQL Server, using the Express version is still better than staying with the Jet engine. A lot can be done with MS Access and SQL Server, and and a whole lot faster than by using .NET, specially if we are talking about an application for that basically does CRUD operations. I think the original poster is just a hater that just can't figure out MS Access & VBA. Saludos!
-
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
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.
-
- 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 -
- 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, 2013Thanks John
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I agree with you a 100%. Even if the customer cannot afford to buy the full fledged MS SQL Server, using the Express version is still better than staying with the Jet engine. A lot can be done with MS Access and SQL Server, and and a whole lot faster than by using .NET, specially if we are talking about an application for that basically does CRUD operations. I think the original poster is just a hater that just can't figure out MS Access & VBA. Saludos!
Member 11652832 wrote:
I think the original poster is just a hater that just can't figure out MS Access & VBA.
That's not true at all. I've been doing VBA on side projects for many years. Anyone who knows both Access and .Net also knows that Access/VBA is very limited compared 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 agree with you a 100%. Even if the customer cannot afford to buy the full fledged MS SQL Server, using the Express version is still better than staying with the Jet engine. A lot can be done with MS Access and SQL Server, and and a whole lot faster than by using .NET, specially if we are talking about an application for that basically does CRUD operations. I think the original poster is just a hater that just can't figure out MS Access & VBA. Saludos!
Are you claiming that MS Access performs/runs faster than .NET application doing the same thing? I don't agree with you on that. In my experience, Access processes ran significantly slower compared to .Net equivalents. Unless you meant the time to develop/implement -- for example, whiping up a front-end app, I think you have point in which creating an acesss front-end typically takes less effort than a .Net front-end.
-
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.
Kevin, as with all projects, determine the clients needs, then see if the existing solution meets those needs. Changing a solution just because the current solution 'sucks' in your opinion (and many others I realize) is not a real answer. If it is a small office and Access is doing it's job with minimal issues, then why force them through the change? You could suggest an upgrade path to them of migrating the backend to MS SQL (or Express) or another database (speed, stability) and then going after the front end. We use a custom app that is Access based and are currently migrating to MS SQL as the backend. We've gotten around the updating issue by forcing a copy of the front end to each user when they start the app. That way they always have the latest code and no user is more than a day away from an update or fix (or a simple exit and restart). Personally, if I had my choice, I'd convert the front end to a rich web app with the SQL backend. Eventually we'll get there, but cost is always an issue.
-
Member 11652832 wrote:
I think the original poster is just a hater that just can't figure out MS Access & VBA.
That's not true at all. I've been doing VBA on side projects for many years. Anyone who knows both Access and .Net also knows that Access/VBA is very limited compared to .Net.
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Limited, yes, but it doesn't make Access a handicapped product. It is not a one size fits all for sure. In my personal experience, the magical number for concurrent users is around 22, though you will start to feel the weight at 12 concurrent users. As for the limitations of the database again, move to SQL Express. The benefits are endless, and you still have an environment that allows for fast development. Trust me; there is still a lot of magic in MS Access and BTW, despite some gossips going around; Microsoft DOES NOT have plans to discontinue this product, as there is indeed a very large user base making use of it, specially as a front end. Fast and dirty? Probably, but never trashy. You can make great looking applications with it.
-
Are you claiming that MS Access performs/runs faster than .NET application doing the same thing? I don't agree with you on that. In my experience, Access processes ran significantly slower compared to .Net equivalents. Unless you meant the time to develop/implement -- for example, whiping up a front-end app, I think you have point in which creating an acesss front-end typically takes less effort than a .Net front-end.
I never said that. I said FASTER DEVELOPMENT TIME. Of course a .NET is going to perform FASTER, though not necessarily BETTER, as this is very subjective and depends very much on the business needs. In other words, yes .NET is better; but is that what the customer needs or wants? You first have to find out if the application fulfills their needs and if the changes they recently required are important enough that it would require not an overhaul but a completely new product. In my experience, if a customer has been using a certain tool for years; our responsibility as analysts is to determine whether this tool will grow with the users needs. That is all you have to find out. Is their database reaching the maximum recommended size? Are there over 20 concurrent users? How much longer is Access being supported? You answer those questions and you'll find out whether you need to create a new .NET application, overhaul the existing one, just leave it as it is or any other solution in between.
-
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.
If they aren't feeling any pain you're not likely to get them off Access. The pain points I've seen in the past are patches that screw it up, locking behaviors that affect other users, and network slowdowns due to Access' habit of pulling records down to work on them. That behavior may have been mitigated by now, I don't know. The only practical way to approach this in a business environment is figure out where their pain points are. If there aren't any, you're kinda stuck. :)
-
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's a thought. Rewrite the UI/logic against the current Access database, but use generic data objects such as oledb which will work with Access, SQL Server, MySQL, etc. There's a real advantage to being able to being able to run an application against more than one type of database. I've done this for many years with the majority of my company's business apps/modules which can run against Access or SQL Server depending on the user's needs. A real benefit of this approach is the ability to grab (downsize/ftp) a sql-based client's database for troubleshooting and quick response. (vs. getting a dba involved)
"Go forth into the source" - Neal Morse
-
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.
How do you sell a wholesale replacement of one technology with another. And Describe the other. Access has UPSIDES (backups are trivial, copy the file(s)), users can jump in and write reports, look at data, etc. But I have replaced it in the past, with: - MSSQL - MySQL - SQLite What is your target technology? Is it truly a multi-user application. Downsides to Access: - Tied to MS OFFICE (upgrades can break it) - Requires additional licenses (these can get expensive) - Mutli-User issues if not designed for it - Size/Scalability - HOURS of work to do pretty trivial things As an owner, you have to show me: 1) I will get my changes faster/easier 2) I will be more secure/safe/backed up 3) I will not lose a critical feature (like writing our own reports, if we do) 4) The savings in the future will more than pay for it. If you can't do that. Then there is no ROI on this change. It is a change to make a programmer happy, in a world where people barely want to make users happy! HTH
-
I agree with you a 100%. Even if the customer cannot afford to buy the full fledged MS SQL Server, using the Express version is still better than staying with the Jet engine. A lot can be done with MS Access and SQL Server, and and a whole lot faster than by using .NET, specially if we are talking about an application for that basically does CRUD operations. I think the original poster is just a hater that just can't figure out MS Access & VBA. Saludos!
Good point about Express and also note that the developer version is now free. The combination of Access and SQL Server is quite powerful and RAD. I'll often prototype a process using VBA recordset (easy to debug but slow to run) then convert the process to use T-SQL. Although I usually use Pass Through queries (PTs use ODBC) to execute SPs, it's nice to know MS have reversed their decision to deprecate ADODB (and therefore ADO). Once you replace your BE with SQL Server then there really isn't much to hate. Even if I do need to use .Net you can always build a COM enabled DLL to consume in VBA. My observation is that some developers, including myself, would love to have a client pay for their time to learn or improve just employ their C# skills. Unfortunately there is rarely a business advantage for the client. Apologies to Gerry for hijacking his thread.
-
Limited, yes, but it doesn't make Access a handicapped product. It is not a one size fits all for sure. In my personal experience, the magical number for concurrent users is around 22, though you will start to feel the weight at 12 concurrent users. As for the limitations of the database again, move to SQL Express. The benefits are endless, and you still have an environment that allows for fast development. Trust me; there is still a lot of magic in MS Access and BTW, despite some gossips going around; Microsoft DOES NOT have plans to discontinue this product, as there is indeed a very large user base making use of it, specially as a front end. Fast and dirty? Probably, but never trashy. You can make great looking applications with it.
MS may have just wasted 6 year of development on Access Web apps which they have now discontinued they are now full steam ahead on developing Access Desktop. Now that Azure allows you to host an Access desktop app in the Cloud there was simply no need for a dedicated Sharepoint hosted version of Access and about the only time Access will not cut the mustard is if you need to cater for anonymous users like on your typical public access web site.
-
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."
I agree with you on the SQL issue and this is a very good case for moving the BE to SQL Server. Developing complex queries in SQL Server is just so much easier. CTEs rock! I'm currently building a very complex report using Access without SQL Server and it really does suck trying to do this in the Access Query Builder. But that doesn't mean you should trash Access for building the UI.
-
- 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:
- 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. If you're not trying to change the systems and just using it Access is stable.
John Simmons / outlaw programmer wrote:
- Access is not secure.
We don't know the size or nature of the business. For a small business with only a few employees it may be sufficiently secure.
John Simmons / outlaw programmer wrote:
- Only one person at a time can have an Access database open for editing at a time.
Only an issue if you need to make changes. For a system that doesn't require changes this isn't an issue.
John Simmons / outlaw programmer wrote:
- Access is limited in terms of what if can do - Access 2010 specifications - 3) Access[^]
Is it meeting the needs of this company? If so then these limitations are irrelevant.
John Simmons / outlaw programmer wrote:
- Access is not intended to be used as an enterprise database solution.
Define enterprise in this context.
John Simmons / outlaw programmer wrote:
- Finding skilled Access developers is becoming more difficult as time goes by because the money is in SQL Server.
Iffy statement on being able to find Access programmers. A good programmer who's already used to VBA can pick up Access relatively quickly.
John Simmons / outlaw programmer wrote:
- Access sucks.
Opinion and not defendable for a small business. Access has a lot of features that make it ideal for a 1-5 person user environment.
-
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 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.