Access 2010 white paper about manageability and migration

Thanks for this! I've been sitting at my computer for 10 hours hacking on a new app in 2010. I love it - however, there are things to learn. I like having a reference book or other source when questions come up but since 2010 isn't yet out, I'm winging it and checking back here. Probably good for me.

On page 6 it mentions that an access webpage cannot retrieve data from sql server tables in separate locations, i.e. different servers, could you not create a linked sharepoint list in sharepoint designer and be able to access the data that way?

I'm working through this document at the moment and would like to suggest that the paragraph on "Compound Indexes" is unnecessarily downbeat. It just says, "Indexes on multiple columns are not supported in Web applications, as explained in the section on tables above".

Probably the most important reason for having such an index is when you want two or more columns together to be unique, e.g. a surname/first name combination, though I appreciate that a multi-column index might also be used to speed up retrieval. However, if the index is used to enforce uniqueness as I suggested, you can do this by adding an extra column to the table, making this single column unique and using SetField in the Before Change data macro to set its value to, say, Surname & "|" & FirstName Thus if you attempt to add the same surname/first name combination more than once into the table, it will get rejected. Reading the document as it stands is likely to have readers say, "What!?!" when they read that paragraph. That was my initial reaction when I discovered this apparent limitation in web tables in Access 2010. Alan PS Personally, I add the "|" to distinguish the two parts of the field's values so I don't get a false clash with surname/first name combinations like Douglass Addam

Douglas Saddam

This is an excellent document which brings lots of information together in one place.

Terry - That great question was asked earlier in another blog post and Clint basically answered that while this is feasible, they had to postpone this feature for next version. But if you can't wait for next version, you could get away with a custom workflow written in .NET to do this. Clint - Thanks for the awesome whitepaper. Reading it, it became apparent to me that I somehow missed the rationale of having non-web databases published to Sharepoint as a mean to facilitate source control and serialize the objects within the application, which was very interesting to me. However, I'm anxious to see how this would be actually accomplished as I've been unable to find the dials to control who can download what objects, what changes they are allowed to make to the objects and who shouldn't be allowed at all to make design changes. I would be very interested in getting more information on this.

@Terry - we definitely want to support virtual lists in the future. This was one of the most painful cuts we had to make. Our goal was to make lists solid before starting to add more external data sources. Definitely see the value... @Alan - I have a blog post coming out on how to use the before change event and LookupRecord in data macros to ensure uniqueness across columns. There is an even easier way without storing redundant data. @Banana - We haven't exposed all the dials possible for fine grain control. For now the permissions of the site should control the permissions of the objects stored in the msysaso list. If you give someone contributor rights they won't have permissions to modify objects but can modify data. We have a blog post on the topic in the works.

Is there any way to get back the look and feel of Access 2003? I still have not gotten used to the menu systems in 2007, and it is still costing me more time than it saves.

Dave @ sorry--there isn't a way to go back to the menus and command bars model of 2003. We looked at it but the engineering, training and overall user experience confusion costs were too high.