ACCDE’s are not supported in Access Services on SharePoint 2010

Any idea yet if the next version of Access Services will offer support for accde? It'd make a big difference. Or maybe a more realistic query, when will you guys be able to start talking about the next Access? I'll quickly mention some other issues I ran into with hybrid apps. Hybrid Access Services a very nice aspect of Access 2010, but has some limitations and gotchas. [1] The package solution wizard does not allow you to select an accdw as the primary distributable. On my first hybrid app I therefore selected the accdb, not realizing how central the accdw is to hybrid apps. The app ran fine for the end users, but eventually there was a serious loss of data with a disconnected user because the sync operation was not integrated into the app's config as it would have been had the app's shortcuts pointed to an accdw. Until this issue is fixed or has a workaround, it's probably better to skip the package solution wizard and use inno setup or something else if you need to distribute a setup.exe [2] If some users will use the hybrid app with the Access 2010 runtime, make sure that you don't hide the Access status bar. That's were the "reconnect to sharepoint" messages will appear after they use the app in disconnected mode and then reconnect. If you're using retail access, there is a major message up in the ribbon area too, but that goes awol with the runtime. [3] Hard to explain this in a short post, but you can get into issues with the rather loosely coupled structure of a hybrid app if you need to redeploy it, esp if you've renamed the application. The cached accdb and the shortcut that points to it from the original deploy may not be automatically replaced, leaving a pointer to an invalid version of the app (the first version.) [4] I found that changing macro conditions does not trigger the "need to sync to server" flag. [5] While you can select two columns in the table designer for a web db (a hybrid app is a variant of a web db) and seemingly mark them as unique, the unique index (or whatever it's called in sharepoint-speak) which gets created involves only the first field. That's a limitation of web dbs, for sure, but it's also a tooling error. It shouldn't allow one to set the unique attribute when to cols are selected, if that capability is not supported. There are probably workarounds for the limitation where a data macro would check for the uniqueness of values in a pair of columns. [5] The ability that Access Services has to sync UI changes is pretty nifty. But I found that there are some unexpected pathways in there. If you add a new table column, in my testing the new column is immediately forwarded to sharepoint; if you check, you'll see that Access suggests that there is no need to sync to server (and it's right). But if you change a table attribute, for example make a column required, that mod is not forwarded to sp automatically. You need to sync the change. I'm not sure why it's inconsistent but be advised. [6] Also, you can certainly sync design changes to the server while everyone is running the app so that the application becomes inconsistent. There does not appear to be a built n way to assert to your users that they *need* to sync for changes, and Access does not warn them. It means that you could make changes which basically break copies of the app that are already open, rather ungracefully crashing the app in some cases. BTW Ryan, the chart above doesn't show the check marks and x's in firefox, just some funny looking u characters. It's ok in IE.

Hi Michael, about point five, have you already checked blogs.msdn.com/.../composite-keys-in-web-databases-through-data-macros.aspx

"Composite keys (multiple field indexes) are not supported on Access Services; however you can use Data Macros to get the same behavior." ?

Hi grovelli - thanks for the reference. I'd assumed that such was possible. My comment was partly about the tooling aspect, where you can appear to set a multi column index in the designer. Months ago a sophisticated Access dev told me that was how you set a multi column unique key, and I had to show him that it doesn't stick.

@Michael Updated the post so the table is viewable in Non-IE.

Thanks Ryan...not a pretty in IE or as interesting in Firefox. Can you put it back?

Thanks for clarifying this Ryan.

So for those interested in having a local copy of access on the user’s machine and also wanting the code for this local copy to be inaccessible to the user, Sharepoint is not an option. With all the enormous investment in Access by so many engineers and all the hype and talk and excitement and exhilaration, I try to think what advancements have been introduced to Access since the 97 version for the above stated scenario, namely having a local copy with hidden code. I dare say not much. Many new features have been introduced, which I personally appreciate very much, but not the basics of the basics, the bread and butter. No improvement in deployability, in security, etc. Is the scenario that I listed above so rare or out of the ordinary? I think not. It is probably the more common one. Settling for a Web application with no local copy is settling for less local possibilities and functionality. Sorry for being negative. I don’t mean to be but I really think something about the thinking remains wanting. Gilad

I agree with Gilad that not having accde available with hybrid Access Services apps is a serious limitation. But I think we have to realize what a major feat hybrid apps are, even with the current shortcomings. It's version 1 of a 'whole new thing'; and it's be surprising if the Access team didn't bring some major improvements to the next rev. Let's hope accde is supported. I mean, take a look around for any technology that supports disconnected users in as simple a manner as Access 2010 does. There isn't anything like it. I wish it was pushing data into sql server/sql azure instead of sharepoint, and I wish many other things for hybrid too. But for version 1? It's a very promising start.

Do you ever have to create another user table on the access database once you publish it to sharepoint? I'm still not sure how user permissions are controlled or synced between the web and when the user opens it in the access program.