BLOGS BY TOPIC▼
BLOGS BY AUTHOR▼
BLOGS BY YEAR▼
Posted by Andy Brown on 09 January 2014
You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.
Access 2013 - a summary of new features (web apps)
I'm not sure that the title of this blog is correct. A better title might be:
A little history helps to understand where Microsoft are heading with this change!
Having read this blog, you can get a good idea of the scope and functionality of Access 2013 with regard to creating web apps here.
Publishing data on websites - a potted history
Ever since the Internet was first invented, companies have been wanting to find a quick and cheap way to put database forms online. In a Windows-based standalone database it's easy enough to create criteria forms like this:
A search form, allowing you to choose what to look for.
A user can then add, edit and delete data via pretty forms:
You can add, edit or delete a data through a user-defined form.
The problem was this: how to reproduce forms like this on a company's website (or even better, on the world-wide web)? Here are some possible solutions, in the approximate order in which they were introduced:
|Active Server Pages||ASP forms were cumbersome to create - only developers had the time and expertise to write the reams of code needed to get them to work.|
|Data access pages||Introduced in Access 2000, I believe, these were finally phased out with the introduction of Access 2007. The theory was that you could publish forms directly to a website, but they were an idea which was years ahead of its time.|
|ASP.NET / PHP||Two alternative technologies for scripting forms on a website - the problem, as ever, is that you need to be a developer to learn the underlying programming languages and technologies.|
Fast forward to 2013
Undaunted by the failure of data access pages to take off, Microsoft have come back for a second, much better thought out bite of the cherry. You can now create web apps, and publish them to SharePoint (either on Office 365 if you have a subscription, or to your company's SharePoint installation).
The clue is in the order: when you create a new database, a custom web app is the one which is presented as the first option.
You can now create a fully-fledged database, including tables and forms, and publish it to your company's Intranet or to the world-wide web. The resulting website created automatically on the web server will use the following software:
|Web mark-up language||HTML 5|
Because the forms have to be created in HTML, you lose the ability to position controls exactly where you want on a form, of course.
One of the best things about publishing a web app is that when you do so Microsoft will automatically create a SQL Server database behind this cloud-based interface. I dread to think how complicated the software to keep your development database and the live database in synch must be.
So rather than asking what new features there are in Access 2013, it might be a better question to ask: how does the new web app development tool bundled in with Access 2013 work?
Changes to the legacy Access
As far as I can tell, the underlying Access database software hasn't changed at all, except perhaps for the worse. No longer supported are:
- ADP projects (a shame, as they're widely used within Wise Owl)
- Pivot tables (although these actually were lost in an earlier version)
So if your main purpose of using Access is to develop Windows-based systems to run on your company's network, I'd strongly recommend NOT upgrading to Access 2013!