Persuade Client To Convert From Access
-
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.
-
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.
-
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
>- Requires additional licenses (these can get expensive) Not if you install Access runtime licences
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
-
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.
I think when it comes to cost it's important to factor in technical debt and the cost of a poorly designed database. In my experience Access actively encourages poor database design as it is so easy to set up badly. The point you make about Access being used as a front end is a good one - it's the equivalent of a poor man's WinForms setup(that is it doesn't necessarily require someone with software development experience to set it up) although it does carry with it some problems such as VBA. I think until Access has something like transaction logging I would not consider it as a database platform on which to base a medium sized upwards business.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
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.
obermd wrote:
but for a single user tracking a small number of items
I used it as a database for up to 10 users in the 90s along with SuperBase, it sounds like Access has come a long way since then. I very quickly converted to using SQL Server and never looked back.
Never underestimate the power of human stupidity RAH
-
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 vaguely remember that which is why I would use the query designer which worked most of the time until you needed something more than a simple join.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I vaguely remember that which is why I would use the query designer which worked most of the time until you needed something more than a simple join.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Agree with you there, the awkwardness of simple SQL querying in Access is legendary. With great respect towards cool features like the crosstab queries, the pivot view, the query designer and the Relationship manager, the embedded Forms and Reports which are all great stuff. The lynchpin though is still the awkward querying and the way Microsoft treats Access development as a misfit orphan. I cut my DBA teeth on MS Access 97. It was great going till v2010 and it all went downhill thereafter. I'll not even touch the VBA part, it gets me so when one realizes how much Excel has received and what Access has been taken away from. I believe that the time has come to part with Access as a serious business development tool. Today in 2017, if a client is looking at enhancing Access to serve business needs, I always remind them of the proverb 'The professional uses a sharper axe to fell a larger tree, where the dilettante makes do with his trusty blunt one' The difference is in the style and execution. The latter believes that serving the current set of needs is a great achievement. The former believes the forest lies in wait for him. He believes he has just begun.