|
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.
|
|
|
|
|
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.
|
|
|
|
|
What you want is "We should rewrite the app"
But, they will say, it works! They got a point here, haha...
If, for example, all they want is to "add 1 button", then rewriting the whole app for that is overkill...
On the other hand if the app is undergoing regularly maintenance and development, how much time will it takes to get the new WPF app is a critical argument. As well as the on going benefit after that, such as better performance, faster developement, easier maintenance (aka less long nagging bug).
|
|
|
|
|
I worked on Access databases for some 12+ years building business applications using Access.
The way I would answer the question is that it is not so much that Access itself is an issue, although it certainly has its issues, it's more to do with the quality of person you will be able to hire who is willing to work on Access.
There is a bigger pool of experienced developers and DBAs able to support MsSQL and Oracle etc than Access. Access tends to attract the hobbyist(I use the words "tends to" with caution as there will be outliers and some brilliant DBAs and developers using Access).
Statistically speaking you have a much higher chance of a decent quality database if the database is one that requires a good understanding of data and databases in order to set it up - Access does not fall into that category.
Oracle and MsSQL etc will deter anyone wanting a quick setup - Access actively encourages and attracts users who are completely ignorant of databases and want a 'quick fix'.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
=========================================================
|
|
|
|
|
Apple has continued (IMO) down the path of releasing software that doesn't live up to the beauty of their hardware. I updated my iPhone 6 to iOS 11 and put up with the first week of slowness, and crashes, and poor battery life, but even after an acceptable period of burn in the phone is just awful to use now. Apps can take 5-10 seconds to load. The camera can take even longer to be ready to roll. It's a huge shame, really.
Even so I'm not willing to move to Android for a bunch of reasons and there's really no alternative, so I've been thinking about moving up to a (relatively) cheap 7. That means I'm going to lose my headphone jack. I'm getting the shakes thinking about that.
Lots of phones have now gone jackless so I was wondering if this has generally been a good thing or a bad thing or a meh thing.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Lots of phones have now gone jackless
Because the manufacturers don't know jack...?
Seriously, Android phones typically work fine with Bluetooth earphones, but I don't know if iPhones do so. It would be just like Apple to lock you in to their solution.
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'd be getting airpods, and any bluetooth headphones will work.
I guess my question is: has anyone gone into this thinking it would be an utter PITA and come out wondering what all the fuss was about. Or, did they go into it thinking it would be OK but there were all these "ah, I didn't think about that" issues.
I really just wish the iPhone was USB-C.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: and any bluetooth headphones will work.
Yes, but not as well, sound quality over A2DP sucks. And while Apt-X is ok-ish, it's of course not supported by Apple. Since it wasn't invented by them.
Apple uses lowish bitrate AAC which is better than A2DP but still inferior to Apt-x.
Personally I'm having a pair of Sennheiser Momentum, which was a compromise on a few parameters. (comfort came out as the winner, had I gone for sound I would've chosen Bowers&Wilkins P7)
They support Apt-x but I'm actually using them with the cable most of the time, since the sound get's so much clearer and less compressed.
But if you're getting earpods this whole discussion on sound quality is moot.
|
|
|
|
|
I'm getting these:
ATH-DSR7BT
for christmas, they probably won't need a cable to sound awesome.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Oh bugger, I wish these had been around when I bought mine.
|
|
|
|
|
My main problem with going jackless is that I now have two sets of things to charge: The phone, and teh earbuds/headphones. They never seem to be in synch, so I am always recharging things over night, whether they need it or not. The headphones I use at work (Bose) can go for several days, but the little earbuds (also Bose) may not last the day.
A human being should be able to change a diaper, plan an invasion, butcher a hog, navigate a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects! - Lazarus Long
|
|
|
|
|
|
I found it funny that it started out with an ad for the windows phone. Even Bill gave up on that and went android.
(Not that I minded mine, other than MS could never manage to actually fix a bug).
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
(disclaimer, I still have an iPhone 6)
I've been using it with an Senheiser HD1 for a few months now with good results. (edit: I've had bluetooth connection pre-iOS 11, but now everything's nice)
It's not the smallest or cheapest wireless in-ear headphones, but it has pretty good battery life (which is my main requirements with any electronics) and the sound "profile" fits my hearing.
I don't have any particular problem with iOS 11 on my iPhone 6; I don't have the need right now to upgrade, and I will be waiting for the iPhoneX reviews and decide if an iPhone 8 or X will be the next one.
I'd rather be phishing!
|
|
|
|
|
I hear you can get a Windows Phone pretty cheap these days!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Did you?
I already bought my Lumia 640 about a year ago, unlocked, $120, with taxes, and delivered at my door. The only Lumias I can still find today are way more expensive, now that MS has pretty much made it official they weren't putting more money into it.
|
|
|
|
|