Archive | SQL Server RSS for this section

Access 2013 Web Apps

A colleague and myself recently embarked to build a small application for our own purposes.  He, being more SharePoint-centric than myself, was an advocate of building it using Access 2013, which has newly added capabilities to live as a web app, in SharePoint.  I scoffed at the notion, after noticing that it was a very scaled-back version of Access that lives in his Azure environment.  What got my attention is how powerful this idea is.

We all know what SharePoint is good at.  No, not document management. Well, at least thats not what I’m thinking about right now.  Its a brilliant list manager.  List managers are key, implemented successfully across alot of the Microsoft stack:  MS Project, Outlook, TFS, Excel of course.  Each has list-management qualities.  Lists are not great when you have truly relational data.  SharePoint has some great portal capabilities.  We know that part of the demise of MS Access has been the power and ease of SQL Server, but the main culprit has been the product’s “desktop” stigma.  In this day, very few databases can simply live within the domain of the desktop.  Even the app that I’m building with a colleague has shared data, and a need for centralization.  Yes, there are approaches to this in Access desktop apps, but they are convoluted at best.

Dismissing Access Web Apps, I turned my attention to viewing my solution as a web application.  In doing that, you realize, being “done” just got alot further down the calendar.  Our needs were not that sophisticated, from a data capture perspective.  In revisiting Access 2013 Web Apps, we saw a model tied to the concept of designating a field as “lookup” data type, in order to associate it with other tables, establishing standard one-to-many and many-to-many relationships.  Once those are setup, building the UI becomes some simple drag/drop operations, yielding a nice database and basic UX within a couple of days.  Whats amazing is that deployment to SharePoint means native data in SQL Server, not Access.  Nicely, that means SSRS reporting, scalability perks, and feeling a bit decoupled from Access in the traditional sense.  Our goal, being to get the UI completed quickly, was to leverage the data in order to populate an Excel sheet, perform some data analysis and begin making use of our new data.  Check it out, if you get a chance.