Jim Dettman
jimdettman at verizon.net
Fri May 23 14:42:08 CDT 2014
A2013 doesn't support command bars...it's now no longer possible to hide the ribbon. A2013 doesn't support JET 3.x or prior. You can no longer open anything prior to A2000. A2013 doesn't support the DBF format. A2013 doesn't support ADP's. A2013 doesn't support replication. A2013 pivot charts and tables are gone. So from the desktop viewpoint, A2013 no longer has a number of features which we've used over the years. Hence it was the last "full" version. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson Sent: Friday, May 23, 2014 02:09 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access and Office 365 (SharePoint) >> Access 2010 was the last full featured desktop version for anyone used to working with Access these past twenty years. In what way is Access 2013 NOT full featured that 2010 was?? -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman Sent: Friday, May 23, 2014 2:05 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Access and Office 365 (SharePoint) You summed it up very well. I can't say too much because I'm under a NDA, but anyone looking back over the previous couple of versions should realize that development on the desktop side is done. Microsoft has made the web it's focus and it's nothing but the web. Access 2010 was the last full featured desktop version for anyone used to working with Access these past twenty years. << But the Access team is currently working on big changes (those were the words) to improve the features of Access/SharePoint combined.>> Certainly they will because as you pointed out, that's where all the resources will be spent, but I would not hold my breath on the "big" changes. A Microsoft employee posted on a public blog a while back about Access and suggested that Excel be used for reporting. That suggests no report writer. And looking at the current A2013 web app offering, all you have is basic CRUD operations and everything looks the same. Forms, controls, and events are all very limited. The current recommendation for whatever a web app won't handle is to use a desktop database and a "hybrid" approach to app development. I really wish that had just made the web side a separate product. There's so much confusion from users over the fact that "Access" is not in any way, shape, or form "Access" when you take it to the web. It's a totally different animal and a totally different product. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Friday, May 23, 2014 12:49 PM To: Access Developers discussion and problem solving Subject: [AccessD] Access and Office 365 (SharePoint) Hi all Just attended for three days the Office 365 Summit here following the SharePoint developer track. Besides that Office 365 including SharePoint moves so fast - and will continue to do so - that you will have a hard time to get up to speed, an interesting statement was, that Access has a top-priority for creating "Access style" apps running in SharePoint which is mostly anything involving more than one table/list or a spreadsheet. Currently, as we know, these Access apps are quite limited because the only programming language is the new weird macros. Why it is so, we were told, is because the macros are converted to SQL stored procedures behind the scene, and this is because the "Access" tables actually are SQL tables in an SQL Server database created for the app. But the Access team is currently working on big changes (those were the words) to improve the features of Access/SharePoint combined. This is the only focus for the team, thus - if you were in doubt - you can forget about any improvement or new feature in Access not related to SharePoint. Also, now I understand why it was so hard to understand programming in SharePoint. The reason is simple; the previous SharePoint SOLUTIONs from up to SP2010 (which are very difficult to program and deploy) are left behind in SP2013 and onward in favour of SharePoint APPs. SP solutions can still be programmed and will run, but you should only follow that route for special cases. These apps are written in JavaScript and CSS, so if you have wondered if you should learn JavaScript or not, don't hesitate - just start, better tomorrow than the day after tomorrow. And while you are at it, get familiar with REST, OData and JSON because this is how all apps in Office 365 will communicate. /gustav -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com