|
Chris Maunder wrote: You mean it's not even easy as a HTML app?
Easy, yes.
Complicated? Definitely.
There's no firm foundation out there. Everything is shifting sand. 
Microsoft, the world was easier when you pwned us devs. 
|
|
|
|
|
raddevus wrote: Microsoft, the world was easier when you pwned us devs.
That's so sad because it's so true and it makes me feel dirty and wistful at the same time.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: makes me feel dirty and wistful at the same time.
That's the perfect explanation of how it feels. 
|
|
|
|
|
raddevus wrote: I thought it was supposed to be one world with one platform by now, eh?
I believe this classic xkcd[^] applies.
|
|
|
|
|
Jörgen Andersson wrote: this classic xkcd[^] applies.
That is probably the best explanation of the situation I've seen.
|
|
|
|
|
The only way I can see around this is if some new framework which includes a virtual machine that has all the dependencies resolved comes into existence. The framework vm would then need to kick out the binaries with all dependenceis mathematically proven. Then developers will have a development environment that 'works' and a deployment that is proven.
I say all of this from living in cloud cuckoo land...
One of the issues I have seen where we all pull from trunk and 'some people' download and make changes that are then not submitted to trunk so that the build works perfectly locally for them but then trunk is broken and it takes a few days to fix trunk.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 24-Oct-17 4:26am.
|
|
|
|
|
Would require actually hiring people.
Wish me luck! (I seriously doubt the company, a global company) will go for it, as it will require them front-loading 50% of the payment for the staffing process, but I figure my proposal could at least serve as a baseline for vetting proposals from "real" companies that already have the existing staff to handle something like this.
Who knows.
|
|
|
|
|
Or possibly, your proposal will provide the method for them to do the project in house and the cost to justify not out sourcing.
It's happened to me on major difficu;lt engineering projects. They had the people and the resourcxes to do things in house, but didn't have anyone who knew what to do.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Walt Fair, Jr. wrote: your proposal will provide the method for them to do the project in house and the cost to justify not out sourcing.
I was actually going to suggest that they use in-house people and I can provide the overall architecture and project management skills.
|
|
|
|
|
So, is it $1.2M if you run it; or if someone else runs it?
The implication is, since you know more, any other response should "cost more" due to exta ramping; which makes your estimate (too) "low"?
(We estimate ourselves; then we project).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Good luck! 
|
|
|
|
|
Hey, you don't get anything you doh't ask for. Good luck man.
Jeremy Falcon
|
|
|
|
|
1.2M is, what, 6 full time salaries for a year including benefits and costs? A decent sized company should see that and not have a problem at all if the outcome is solid.
Go in, go hard.
cheers
Chris Maunder
|
|
|
|
|
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.
=========================================================
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
