Persuade Client To Convert From Access
-
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. =========================================================
-
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
-
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.
-
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