Alternative for Access+SQL Server for enterprise projects [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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)

Answer 6

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.

Answer 7

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.

Answer 8

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.