The Access Show: Developing Access 2010 Hybrid Apps with Dick Moffat

Terrific job guys – It was great to see the Access 2010/SharePoint 2010 story conveyed so concisely. This new approach to wiring up your Access applications into SharePoint is a buried treasure inside Office 2010.

This is a very interesting video. Thanks for posting it. One question I still have has to do with protecting or hiding objects and code from users. I find this to be a crucial matter and am still baffled about it. I understand that the SharePoint Log-in names restrict what users can do with the data and restrict their ability to commit changes to the uploaded file on Sharepoint. But what about the local file? Can a user that is not marked as an Administrator on the SharePoint site view the objects and view the code on the local file (before committing them up on to SharePoint)? Does the local file on the local machine know that the current user is a SharePoint site administrator? I think that mentioning AccDE (as opposed to AccDB) here may be relevant. Is it? Does it come in the game anywhere? With regard to the disconnected scenario: What happens when there are clashes and conflicts between records that have been added or updated by different users? I understand that there is a conflict manager that comes up when the data is synchronized, but then does this mean that the first user that gets the conflict manager going “wins” and has the ability to determine that his changes will supersede the other users’ conflicting records? Thanks

Gilad

@Gilad But what about the local file? Can a user that is not marked as an Administrator on the SharePoint site view the objects and view the code on the local file (before committing them up on to SharePoint)? Any user with permissions to the site (read/edit/design) can view all the objects/code in the local copy. ONLY users with design permissions can push changes back to the server. Acess Services does not support ACCDE this release. What happens when there are clashes and conflicts between records that have been added or updated by different users? The conflict manager shows the user both conflicts and let's them pick which one to keep.

Is setting a database password supported? I know that passwords can be cracked, but it would keep the average user out of the code. Is there any plan in the future to support an AccDE? If an app is going to published to the cloud, complete security could become a requiement.

@Jack Stockton database passwords are not supported for Access Services Web Databases. You should contact us through the "Email Blog Author" link and tell us more about how you would use ACCDE's in this context.

I enjoyed the video. When I use queries in a database, I often write the query in VBA and produce it on the fly. For example, I can use set qdf = CurrentDB.CreateQueryDef("MyTestQuery",SomeSQLStatement) for a named query. I can then drop or recreate the query dynamically, which is very useful for those who may "unintentionally" alter a query. Anyway, will these type of object creation/deletions with VBA be supported in the hybrid environment?

@Art those type of VBA created queries will be supported.

@Ryan McMinn "Any user with permissions to the site (read/edit/design) can view all the objects/code in the local copy." "You should contact us through the "Email Blog Author" link and tell us more about how you would use ACCDE's in this context." Isn't this a serious issue? How are developers expected to distribute their applications when there is no way of hiding the application's code or objects? I guess the only way would be to use previous methods like the much expensive Sage key scripts or the like and wait until ACCDE's will be supported.

I just threw a password on the VBA Project of an Access Services database with Modules and that worked. I can't get to any VBA (even behind forms of course) without knowing the password. It's not perfect but it's pretty nasty :-) ... Is this another argument for using "Hybrid" apps rather than fully Web Apps? Inquiring minds want to know ... ***

Gilad, if you need to secure your code and the apps base objects, out of the box hybrid apps not be the route for you. I have that need also; any 'commercial' app has a requirement like that. For apps that are deployed within corporations, sometimes an accdb or mdb is ok. I've distributed a lot a apps that way and there has never been an instance (that I know of ) of a user mucking about with the vba or queries. So I'd say the hybrid app solution is very useful in some circumstances, and not ready yet for other deployment scenarios. BTW, nothing in the sagekey scripts would help with securing your code.

Biggus, there are a couple of solid reasons to consider a hybrid app over a web database. Off the top of my head: - rich user interface

- vba code support

- disconnected data

- local data The two last items are really different facets of the same feature. Disconnected data means your users can still work with the database if they're not connected to the mothership. Local data highlights the fact that all of the app's data is copied from sharepoint to the local accdb. Some operations may run faster without needing to traverse the network. Having all of the data local can be a minus of course. Another minus that could come into play with hybrid apps the lack of support for accde. With a web database the app remains on the server. One thing I wanted to add to the 'plus' list above is access to the local file system. But maybe one can get to the local file system with a web database? Does anyone know?

Just thought of a problem with the hybrid app...all the data is copied locally, therefore it can be stolen. Anyone thought of a way to protect the data other than using something like BitLocker? This maybe a reason to use the web app.

Hello guys, I'd call this Pac-App (Package-Application). Seeing how things are being 'packaged' and send off/read from SharePoint 2010 servers. :) Same with the updates, where new information are 'packaged' nicely and delivered upon online connection between SharePoint server and Access application. No, I don't work for any delivery company, I just thought of receiving 'presents' in packages, while viewing this video presentation. And it is a good warm-fuzzy feeling to receive gifts. :) Thanks!

Jack Stockton wrote: "Just thought of a problem with the hybrid app...all the data is copied locally, therefore it can be stolen. Anyone thought of a way to protect the data other than using something like BitLocker?" Not likely. Since the data requires the user's login be assigned some kind of rights on the SharePoint site to even get at the data on the client machine and since the temp file exists INSIDE the user's "Personal" Documents folder the chances of someone getting in without them knowing it is significantly small. Yes, if they copied the data and gave it to someone that wouldn't be nice, but the same is true of any app which allows you to print reports or extract to Excel anyway.... it's the human that is the risk not the software :-). That's an HR issue ratherthan a technical one IMHO. Yes probably some genius could eventually hack into their folders (or an admin which shouldn't be an issue anyway) but IMHO this is more than tight-enough security for 99% of needs. If that's still not enough then you should be using a SQL Backend or something like that anyway. But those other risks I alluded to earlier will still apply. But SQL Backends (as we said in the video) can still be an Access Services "Story" as well. ***

Michael: A "Web" app can only interct with objects and data that is on the SharePoint Access Services Site. There is no interaction with local or other network resources. This may seem like a nuisance, but it can be worked around by having an application that's actually part Web-Only objects and part "Hybrid" ones that manage the data being fed to and from the Access Services Site as necessary from and Admin app. ***