[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