7

We're a small software company, developing projects for manufacturing facilities about analysis, traceability, reporting etc. We're using Access for front end, SQL Server for back end. We've quite big customers too and our company is growing. So far it is working fine but I wonder should we move to more influential technologies, such as web based solutions. What do you think about the future of Access?

Deepak Rama
  • 79
  • 1
  • 1
  • 2

8 Answers8

8

Applications written with Access and especially Excel tend to pop up in organizations whenever very specific business problems need to be solved quickly and in an ad-hoc manner with zero to minimal support from professional developers. These are GOOD and POWERFUL tools and this is a perfectly valid way to use them.

The problems start when requirements and problems become more complex and the existing ad-hoc systems based on Access or Excel can no longer keep up either because no one is maintaining them or the scale is just getting too large to handle.

I don't think your organization has these problems. Why? Because you probably have people dedicated to the development and maintenance of this product who presumably have strong control of the application and the way it scales. In the right hands and in the right context, Access is perfectly capable.

I think the real problem is finding people to develop/maintain this application in the long term. Access is just not as attractive/glamorous as other technologies. That alone could be enough to at least consider migrating to other application platforms.

Angelo
  • 1,614
  • 13
  • 9
  • I have to disagree - The first sentence is spot on & the second I have major issues with. End users should not be writing mission critical applications and Access makes it so easy they end up doing so. I have personally had to handle the fallout of poorly written, unsupported Access applications providing business critical functionality. If I had my way Access would be uninstalled from end users' computers. Excel is a whole different series of issues because every cell can contain a mini-program and the end users often haven't got a clue of how to test and validate the data... – mcottle Sep 08 '11 at 01:28
  • I've done the same stuff cleaning up "fallout" from excel "super macros". However, that's just the reality of business. Sometimes things need to be done very quickly without the luxury of a dev team to do it right. That's OK. Many business applications start their life as a zany macro on somebody's laptop. The specific case of the OP is course different. – Angelo Sep 08 '11 at 02:16
6

Access, the application, will be around for a long, long time. It has value and a place in the IT world but Access is NOT an Enterprise level solution. Period.

You need to build a front end in C# or VB.NET (assuming you're keeping in the MS stack). You have a lot of choices, WinForms, WPF, ASP.NET, Silverlight. And which one you choose will really depend upon your business, your application and the direction you want move towards.

If you are building your company on this application then it is time for the company to mature and grow up into a mature front end.

Walter
  • 16,158
  • 8
  • 58
  • 95
  • 1
    While I agree that Access is not an Enterprise solution as a database, it most certainly can be put to good use as an environment to develop the front end to a MS SQL Server database. Yes, there are other solutions to do the same, but the way MS Access is integrated with Office and with other MS solutions for the enterprise, it may be the easiest way to develop applications that need to integrate with all these technologies. – Marjan Venema Jun 05 '11 at 15:50
  • 1
    Great idea - use a general purpose framework and language to write 000's of lines of code to achieve the same result as Access, only it will be 'Enterprise' grade. – Paul Stovell Sep 07 '11 at 12:27
  • 1
    -1 for failure to support your assertion that Access isn't an enterprise-level solution. There are multiple parts to Access: There's the Access front end, for application design, and the Jet database engine back end. The Jet database engine doesn't support multiple users well enough to use it for an enterprise-level back end, but there's nothing wrong with using Access to create an application with a SQL Server back end. – Kyralessa Sep 07 '11 at 13:34
  • Access is *slow* in some cases, even used as a front end to an MS SQL database. If you're working with large datasets, this is a concern. – asthasr Sep 07 '11 at 15:57
  • 2
    @Kyra sure, if you're a business analyst or sales professional. If you're a professional developer, there are much better tools available. – Joel C Sep 07 '11 at 15:59
6

Access will serve you fine as a front end, even for "Enterprise" applications. I'm not sure what you mean by "influential technologies", but more likely than not it is just hogwash. Tons of really massive companies use Access and (shudder) Excel to drive mission critical functionality, they won't balk at it one bit. Hell, SharePoint is considered way more Enterprisey, and I'd pick Access over that lump of *&$(&$# anyday.

Web, desktop and other front end technologies should be employed when they meet a business need, not imbue your solution with some notion of worthiness. The whole issue sounds like a red herring.

JohnFx
  • 19,052
  • 8
  • 65
  • 112
  • 1
    I'm not a fan of the argument that "lots of people are using it, so it must be ok". Just because enterprises use Access doesn't make it an enterprise-level software development platform suitable for building software intended to be sold to enterprise customers. – Joel C Sep 07 '11 at 16:03
  • +1 -"Web, desktop and other front end technologies should be employed when they meet a business need"...end of story. – Morgan Herlocker Sep 07 '11 at 16:19
  • 1
    Okay. Let me qualify that. I've seen it used **successfully** in many enterprise situations. There is nothing inherently wrong with the tool, you just have to match the right tool to the right job. – JohnFx Sep 07 '11 at 16:21
3

Enterprises care about solutions that work, are usable, can scale to their needs, and that the company behind them are responsive to change and can support the product.

General programming languages like C# or Java tend to get picked because they are assumed to be more flexible, but if you already have a solution in Access, it suggests to me that Access is a fine solution.

Here are some things I would consider:

  1. Is the Access code maintainable?
  2. Do you use source control?
  3. How will you handle any customizations they might need?
  4. Can you hire people to maintain it?

There are good and bad C#/Java solutions, and there are also good and bad Access solutions. Personally speaking, I think more of the CRUD/reporting apps we write with WPF/WinForms/Silverlight should be built with Access.

If you are confident your Access solution will meet the needs of your customers, don't let technical biases peer pressure you into rebuilding something that works.

What you may want to consider is how your product will change to meet enterprise demands. Instead of forms and data, would you like to build more intuitive and task-based user interfaces? If there are features you'd like to add that would be difficult or impossible to do in Access, then that may justify a switch.

(I say this as a WPF/ASP.NET programmer by day)

Paul Stovell
  • 1,689
  • 1
  • 9
  • 14
2

Access can be a great for inter-office application and small scale production applications but the fact of the matter is it just does not scale to enterprise level.

You mentioned that your company is growing and with that growth you need a better front end that represents the cutting edge of technology, and instills confidence in your clients about the technical expertise that your company provides.

Some options:

1) If you are considering a two-tier desktop based application then look at .NET Entity Framework as a persistence framework for your data access with SQLServer. Your views can be designed using WPF. It is one of the best combinations I have seen for two-tier desktop applications.

2) Web-Based, If you are considering the web based approach and you are not too keen on .NET technologies, then look at the J2EE framework and JSF with Hibernate as the persistence framework to SQLServer. There are numerous component libararies available to create rich web applications with clean minimalist code.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 1
    WPF should only be considered if they are also changing the entire UX. If they are just going to rebuild the existing CRUD+Reports solution with WPF then they will get a slower, less maintainable result than sticking with Access. – Paul Stovell Sep 07 '11 at 12:25
  • @Paul - what is the difference between "changing the entire UX" and "rebuild the existing CRUD+Reports". It sounds like a rebuild is in order in either scenario. Also, why would WPF be slower and less maintainable if they did a rebuild? IME proper MVVM WPF leads to some of the most maintainable code around. Sure, if you slop it together with terrible design, it will not work well, but Access is no different in that case. – Morgan Herlocker Sep 07 '11 at 16:24
1

Microsoft Access no longer supports direct interaction with SQL Server (Access Data Projects) it's been removed from Access 2013- the only option is to go through a SharePoint enterprise external connector license which is literally $60 grand.

OpenOffice / LibreOffice has some great abilities to connect directly to mySQL. I haven't used them for a couple of years, but I'll go out on a limb and say that they're easier to use than Access / Jet / Linked Tables. Client-Server is a more efficient algorithm, it always has been.. and it always will be.

Also, Microsoft "Visual Studio Lightswitch" is a great alternative to Access. It allows simple web-based data entry.. I've never integrated Reporting Services with lightswitch, but it seems like a dream come true.

Aaron Kempf
  • 111
  • 3
0

If it is not broken don't fix it. I have used this phrase 2 times this day, and I am not sure it is professional enough but reality proves it is correct time after time...

It is good to anticipate change and be ready for it, but first, you need to clearly define your problem, for example:

  • Do you anticipate large volume of data?

  • Is there a lack of expertise in the current application?

  • Major changes in logic?

  • Do you anticipate more users?

  • Need for distributed processing?

  • Need for web access?

  • Need to support special devices?

  • Need to have more secured application?

  • And so on...

Without answering those questions, you will not be able to pick the right solution for the problem.

Fact: Any technology you pick today will be history in few years time. For example, WPF is now not as fancy as it was promised to be because Silverlight is the new kid in town and even that is being challenged by HTML5+JavaScript and the story goes on and on.

Make sure you add to the above list, the time you anticipate the change is need for and the ability of your staff or your organization to invest in human intellect needed for the migration.

NoChance
  • 12,412
  • 1
  • 22
  • 39
0

I'm guessing that you know that your organisation isn't particularly mature and that you want to improve things and become more professional. So, you will want to ensure you have bug tracking, version control, release control etc.

Given what you have & what you know I'd suggest dropping Access and moving to .NET winforms using VB as the programming language because that will be close to what you have at the moment but will be a lot easier to support - I don't think Access integrates well with version control for example. Stick with SQL Server, it's a fine product. Consider moving to C# instead of VB because C# is a better language & Microsoft is developing C# more actively. It will be harder to make that jump though so you may want to start with VB.

mcottle
  • 6,122
  • 2
  • 25
  • 27