July 22, 2014 at 9:34 am
benjamin.reyes (7/22/2014)
Eric M Russell (7/22/2014)
Andy Warren (7/22/2014)
That said, today in 2014 (and ever since the mid-1990's), there are much better options than MS Access if you're looking for a platform to develope multi-user line of business applications or data marts. In that arena, Access struggles and fails.I'm interested in hearing these alternatives.
OK, what I asserted above is: There have been better alternatives to MS Access for developing "multi-user line of business applications and data marts" since the mid-1990s.
There are way to many to mention, so I'll just mention the Microsoft stack.
multi-user line of business applcations: Visual Basic (superceeded by .NET), ASP.NET, SharePoint, Model Microsoft Dynamics CRM
multi-user data marts: SQL Server, Analysis Services cubes, SSRS, SharePoint
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 22, 2014 at 9:39 am
OK, what I asserted above is: There have been better alternatives to MS Access for developing "multi-user line of business applications and data marts" since the mid-1990s.
There are way to many to mention, so I'll just mention the Microsoft stack.
multi-user line of business applcations: Visual Basic (superceeded by .NET), ASP.NET, SharePoint, Model Microsoft Dynamics CRM
multi-user data marts: SQL Server, Analysis Services cubes, SSRS, SharePoint
I completely disagree with you on this point. I was expecting a list of programs that were better than access as the desktop level. All of these are enterprise level applications. I can design an Access app much faster than a VB/SQL server app that does the same thing. The question is how "big" is this going to get. Size. Number of users. Required performance. Access fills a niche that VB/SQL could fill, but using the latter would be like shooting a squirrel with a bazooka. It's overkill. And your SQL Server now has many more databases than necessary. Having worked with all the major suites as an application instructor, MS Access was far and away above the competition in its class. The ones you mentioned are NOT in its class.
July 22, 2014 at 9:45 am
Ron Kyle Wrote:
... using [VB/SQL] would be like shooting a squirrel with a bazooka. It's overkill.
But entirely legal in several states. Besides, I hate it when those squirrels keep getting into my bird feeders.
Bad jokes aside, I actually have to agree with Ron on this point. It's all about using the right tool for the right job. If a small part of our business organisation needs a relatively simple, straight-forward application developed quickly, Access is certainly a candidate solution.
July 22, 2014 at 9:56 am
GoofyGuy (7/22/2014)
Ron Kyle Wrote:... using [VB/SQL] would be like shooting a squirrel with a bazooka. It's overkill.
But entirely legal in several states. Besides, I hate it when those squirrels keep getting into my bird feeders.
Bad jokes aside, I actually have to agree with Ron on this point. It's all about using the right tool for the right job. If a small part of our business organisation needs a relatively simple, straight-forward application developed quickly, Access is certainly a candidate solution.
Absolutely. Candidate i.e. an option to consider that depends on your particular set of circumstances and requirements.
I haven't utilised Access for a LONG time except to open Access databases to look at someone's data (with their permission, of course). I prefer to not use Access but that is usually because of two factors:
1) My relative lack of familiarity due to non-use for a substantial amount of time i.e. I am not an appropriate Access developer.
2) Almost all development I have done for a LONG time requires a different class of solution i.e. Access was not an appropriate option.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
July 22, 2014 at 10:38 am
RonKyle (7/22/2014)
Also, I'm unclear on the current state of Access development - do you feel the product is moving forward
Although I remain a big fan of Access development if its niche is properly understood, I think the product took a huge step backwards when it changed the security system that it had. It was very nice to be able to develop applications that displayed information, forms and reports in a user security context. I don't understand exactly what's replaced it. I only know if I use Access with Jet, the application objects are now come one come all
ULS (User Level Security) was dropped with the accdb format in Access 2007. It was always buggy and fairly easy to defeat. I've always used a VBA based security model (see my blog http://scottgem.wordpress.com/2010/01/12/creating-login-security-using-access-vba/) for more on that. While still not 100%, when combined with converting to accde, disabling the bypass key and other techniques, it becomes reasonably secure. Since most of my users only have a runtime license, I'm not concerned with unauthorized access to data, at least with the apps I develop for my company.
Scott<>
July 22, 2014 at 10:45 am
Andy Warren (7/22/2014)
Also, I'm unclear on the current state of Access development - do you feel the product is moving forward, or is it stalled? Is Lightswitch (or something else) beckoning you (or the newbies who might try Access)?
What do you mean by development? Do you mean from the Access development team, or from the user community?
Clearly, Access client apps, a desktop front end/back end setup has pretty much stalled. But that' not a bad thing as it is a full, rich environment. Most development on Microsoft's part is geared to created WEB/cloud apps using Access. But that doesn't mean use of Access in the client app is going away or will wane anytime soon.
Scott<>
July 22, 2014 at 11:23 am
fairly easy to defeat
Really? I'd be interested in how (as the information is increasinly losing relavance with the passing of years since it worked). I never found it buggy. It was difficult to figure out as there seemed to be no clear guide. But once figured out, and you were careful to avoid creating the file with the default user, it worked well. As for the file itself, the data could be read. But you could stop that with encryption. For all the security the enterprise apps can offer, my hunch is with all too many applications the security is also fairly easy to defeat.
July 22, 2014 at 11:30 am
Ron,
I have a tool that will read the user name and password from an mdw file. It was freely distributed. As to it being buggy, I must admit, I'm relating what other people have told me. I just found it too cumbersome to use for the little security it gave. So I never got into it.
Scott<>
July 22, 2014 at 11:42 am
Eric M Russell (7/22/2014)
benjamin.reyes (7/22/2014)
Eric M Russell (7/22/2014)
Andy Warren (7/22/2014)
That said, today in 2014 (and ever since the mid-1990's), there are much better options than MS Access if you're looking for a platform to develope multi-user line of business applications or data marts. In that arena, Access struggles and fails.I'm interested in hearing these alternatives.
OK, what I asserted above is: There have been better alternatives to MS Access for developing "multi-user line of business applications and data marts" since the mid-1990s.
There are way to many to mention, so I'll just mention the Microsoft stack.
multi-user line of business applcations: Visual Basic (superceeded by .NET), ASP.NET, SharePoint, Model Microsoft Dynamics CRM
multi-user data marts: SQL Server, Analysis Services cubes, SSRS, SharePoint
All of which are not as fast or cheap to deploy solutions to end users who want a multifunctional gui, or the alternatives have some sort of major limitation. Lightswitch had promise but still has some serious limitations. I really would like an alternative.
http://www.fmsinc.com/microsoftaccess/lightswitch/platform/index.html
July 22, 2014 at 11:50 am
scottgem (7/22/2014)
I have a tool that will read the user name and password from an mdw file. It was freely distributed. As to it being buggy, I must admit, I'm relating what other people have told me. I just found it too cumbersome to use for the little security it gave. So I never got into it.
The way I did it was to read the user name from the environ variable.
Then I would activate or deactivate functions and fors based off of that. People wouldn't even realize what was/wasn't there.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
July 22, 2014 at 11:52 am
The way I did it was to read the user name from the environ variable.
I used the user name to determine the group. The permissions were based off the group.
July 22, 2014 at 12:32 pm
Microsoft seems to have decided that the only solution is a web based solution so it is targeting that paradigm for development and letting client/server slide. I happen to disagree. Call me crazy but my clients don't want a browser based solution. They want client/server. They don't want stuff in the cloud so they don't see the need for the shift. While there are many applications that can benefit from some remote connectivity, most have no need. Some of my clients run multi-site operations or have employees who work from home. For those situations, Citrix has proven to be an excellent solution. The Citrix users get excellent response times, sometimes even better than the local users. And both user classes get to use robust, user-friendly, client/server interfaces rather than the flat, slow, huge (always have to scroll) web pages.
MS has added to Access a third "feature" to make "Access" web accessible with A2013. They've gotten a lot closer with this iteration since they are using Azure as the BE rather than SharePoint (A2007/A2010) or Jet (A2003 DAPs) but they are still way off the mark since the solution includes no coding interface and cannot automate other Office components which Access is used for quite frequently. You are limited to what you can do with macros. So, I predict this will be yet another dead-end unless they include a programming language (either VBA which is the obvious preference by existing developers or Java script which is what the macros compile to) in the next release or sooner. The worst thing about Access web apps is they force you into SharePoint since they require SharePoint to run. So, only if your client has SharePoint, and only if it is the most recent version of SharePoint can you actually deploy an Access web app unless you want to go with a hosted solution. Of course, MS is really trying to funnel everyone into hosted software because it is a constant revenue stream for them rather than the up and down of periodic releases. Plus, once they get us all into the monthly subscription model, there will no longer be the option to keep your old version for 13 years. You'll need to keep paying the monthly subscription fee to keep it running so you may as well upgrade.
Someone asked earlier for active Access forums. Here's a couple more really good ones. Both have non-Access sections.
http://www.experts-exchange.com/ -- this is a subscription site so the support is pretty good.
http://www.access-programmers.co.uk/forums/ -- even though this is a UK forum, a large part of the population is from the US.
July 22, 2014 at 12:36 pm
Patricia Hartman wrote:
... my clients don't want a browser based solution. They want client/server. They don't want stuff in the cloud so they don't see the need for the shift.
Web applications do not have to be hosted 'in the cloud' - they can be hosted 'on premises' - typically using Microsoft IIS or Apache servers. Indeed, before the recent advent of the cloud, this was (and still is, for the time being) the typically hosting scenario.
July 22, 2014 at 12:39 pm
I/we understand that but it's a whole new class of technology they need to have supported if they host them in house.
July 22, 2014 at 12:49 pm
... [web applications are] a whole new class of technology they need to have supported if they host them in house.
Which is why cloud-based hosting exists. But it sounds like your clients don't want on-prem web hosting, and yet they don't want it in the cloud, either.
MS, as you noted (along with most of the world), is moving/has moved to web applications, and there are numerous good reasons (as well as a few bad ones, admittedly) for this. Client/server still has its place, but perhaps it's time for both you and your clients to consider some other application development tools, in addition to MS Access?
Viewing 15 posts - 76 through 90 (of 113 total)
You must be logged in to reply to this topic. Login to reply