|
Is that your estimate of the turnover, or of your profit? 
My great-grandfather used to say (translated from Yiddish) that "turnover is vanity; profit is real!"
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
0) 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
|
|
|
|
|
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.
|
|
|
|
|
I 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.
|
|
|
|
|
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
|
|
|
|
|
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.
=========================================================
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
Depending 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 just posted basically the same thing, lol.
|
|
|
|
|
Thanks John
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
 John Simmons / outlaw programmer wrote: 0) 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: 1) 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: 2) 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: 2) 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: 4) Access is not intended to be used as an enterprise database solution.
Define enterprise in this context.
John Simmons / outlaw programmer wrote: 5) 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: 6) 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 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'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
=========================================================
I'm an optoholic - my glass is always half full of vodka.
=========================================================
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
