Comparison of Microsoft Access, LightSwitch and Visual Studio Platforms for Database Developers

Last month I spoke at the Portland Access Users Group Conference at Silver Falls State Park. I gave a presentation introducing Visual Studio LightSwitch and how it could be used for SQL Server applications deployed on a variety of platforms. As a follow-up, I’ve created a summary matrix and discussion that highlights the features and limitations of the variety of platforms from Microsoft Access, Visual Studio LightSwitch, and Visual Studio.


Microsoft Access started at the beginning of the Windows revolution 20+ years ago and became the most popular database of all time. More recently, additional technologies have become significant, so it behooves the Microsoft Access community to be aware of the trends and options.

Database Platform Matrix

Ultimately, it’s about being able to create solutions that help you and/or your users accomplish their mission. Sometimes the user’s platform is critical, sometimes, it’s the data source, and other times it’s the permissions you have to deploy a solution. A variety of platforms and options are available with benefits and limitations with each. Meanwhile, Microsoft Access is also evolving with their latest Access 2013 version offering new web based solutions.

We’ve written a new paper Comparison of Microsoft Access, LightSwitch and Visual Studio Platforms for Database Developers¬†¬†that summarizes what we’re seeing and experiencing.

6 thoughts on “Comparison of Microsoft Access, LightSwitch and Visual Studio Platforms for Database Developers

  1. Hi,

    Lightswitch:

    i like your comparison. But i think you need to rework the Backend Database part.

    a) with OData you surely can connect to each system which support that interface.
    b) using the older (still existing and fully supported) RIA interface you can connect to which system you ever want, including MS Access.
    c) For using Stored Procedures you hat to use a workaround but you could use stored procedures.

    The points:
    Supports Microsoft Access / Jet (DAO)
    – with RIA services you could write code to support it
    Requires SQL Server
    – only during development time, not in production – Express version is enough (and installed with VS anyway)
    Requires Referential Integrity
    – can be implemented in LS itself – so no RI is required in beforehand
    Can Execute SQL Server Stored Procedures from Client
    – at present – possible with workaround – Standard in VS 2013
    Connect to Tables in Access and SQL Server Databases
    – Access: via RIA Services Other: With OData Services
    Connect to Tables in Oracle or other ODBC data sources
    – via OData Services or RIA Services

    Other Points:
    Web Service
    You can use LS to create a pure OData Interface
    Isn’t that a Web Service ?

    Extensibility
    For VS 2013 read that articles:
    combine LS with ASP.NET MVC
    http://blog.ofanitguy.com/2013/08/07/add-asp-net-mvc-to-lightswitch-2013/

    and the possibillities which are included in LS itself are explained:
    http://softlandingcanadaforums.com/mslshelp/JavaScript%20Documentation.html

    mfg
    Klaus Oberdalhoff (Germany)

    • Just another one:

      If Lightswitch (specially HTML) is not capable of using SharePoint 2013 , why then do i find on TechEd 2013 the following sessions ?

      Building Modern, HTML5-based Business Apps for SharePoint 2013 with Visual Studio LightSwitch
      http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/DEV-B342#fbid=o7HhR3-y9Hp

      and an additional LS online Tutorial (MS Hands on Lab)
      Developing SharePoint Applications Using Microsoft Visual Studio LightSwitch
      http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/DEV-H306#fbid=o7HhR3-y9Hp

      mfg
      KlausObd

      • Hi Klaus,

        Thanks for your feedback. We are committed to providing accurate information so your feedback is much appreciated.

        For the SharePoint 2013 issue, we were trying to show that it was required for Access 2013 web apps. LightSwitch and the other options do not require SharePoint 2013 to work. Maybe we can clarify that better.

        We are trying to show the functionality of each platform without workarounds or code writing. We would not expect knowledge of RIA skills for information workers that might be attracted to LightSwitch. Similarly, we don’t consider web workarounds like Citrix or RemoteApp to be equivalent to web support for desktop applications.

        Regarding SQL Server or SQL Express, we consider them to be equivalent. Are you suggesting that LightSwitch database apps can be deployed without SQL Server or SQL Express?

        With regards to the issues you’ve raised, I’ll have my team review it early next week for clarification. For instance, given your use of ODATA, we’ll investigate how that works out of the box for LightSwitch. We can then compare it to the Access desktop database’s transparent ability to heterogeneous joins between tables from multiple databases and different types data sources.

        Once again, thank you for your feedback.

  2. Nice write up! Going to book mark this and keep it handy. Always tough to explain what works where on what and how. This sums it up nicely.

    Jim Dettman

  3. Luke, I think that there still is some persistant fear that Microsoft will some day abandon the desktop capabilities of Access. For desktop apps, there is no improvement in a move from 2010 to 2013. You can easily imagine Access 2013 branching off as a new product. Why not? Microsoft is justified in preparing itself for what seems to be coming: everything cloud. However, though companies like yours develop Access solutions for the enterprise, most Access databases are in small businesses. That is the beauty of the product: allowing small businesses to develop solutions that fit to the way they worked, and not the other way around. In this they allowed small businesses the level of computerized efficiency that before Access and similar products belonged only to large companies. A small business, that has a good solution developed in Access 97 (the first good version) and upgraded to 2003, does not need more bells and whistles. The tool is good enough.
    I do agree that you cannot stand still; I agree with all of what you have been saying about this subject. However, many of us have made livings developing desktop apps in Access, and porting to the cloud is not an option in most cases. I would be content if they would declare that though they may not continue developing Access as a desktop RAD tool, still they will not degrade the product further (as has been happening since the disappearing tool-bar fiasco), and will continue to support the 2010 version. They can put the development of the desktop version on low heat while moving ahead with web capabilities. By doing that they win twice: they stay in the good graces of everyone using Access solutions (millions), and also, if and when the cloud bursts, they have the fallback tool.

    • Thank you for your feedback. I hear what you’re saying regarding the value of Microsoft Access on the desktop and the great solutions it’s able to create. I would add that even in large enterprises, Access plays a huge role because most large organizations are essentially composed of smaller groups that share the same challenges of standalone small businesses.

      The technology market and Microsoft have made it clear they need to support the new platforms of mobility. Microsoft has made it clear that their investments in Office is to focus on cloud solutions which really means being relevant on mobile and iPad/slate devices. They are still supporting Windows, but my sense is they feel what they have is “good enough” and enhancing it won’t drive more sales. I don’t necessarily agree with that decision and appreciate the points you make, but I do understand they feel threatened by the success of Apple and Google.

      On the plus side, when there is turmoil, there’s always opportunity so technology demands that if growth is important, we must evolve.