Access 2010 beta - Publish to Sharepoint
in [Help]
|
Prev: Keeping A Citrix Session Alive?
Next: Help in A2010
From: Salad on 19 Nov 2009 23:41 David W. Fenton wrote: > Salad <oil(a)vinegar.com> wrote in > news:MdadnciZR77gP5jWnZ2dnUVZ_gidnZ2d(a)earthlink.com: > > >>Bob Alston wrote: > > >>>One requirement that the database be in Access 2007 format. >> >>Would that be a problem? One can link to a SharePoint table with >>A2003. > > > I think you're completely missing the point. Bob was trying to test > the new publish to Sharepoint feature, where you create an ACCDB and > can publish it to Sharepoint, where it will run in the browser and > look nearly identical to the way it looks running in Access. There > was a humongous thread on this very topic last week. > > Linking to Sharepoint is not even close to the same thing as the new > features being offered by A2010 in terms of Sharepoint integration. > I still don't get it. Who cares about the format being a problem if one can publish an app to the web. Is the problem that one can't get to the data unless it's in A2010? Either way, who cares?
From: David W. Fenton on 20 Nov 2009 15:06 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:sGnNm.45590$Wf2.36487(a)newsfe23.iad: > Primary Key: > Use ID, this has been the default PK for ms-access as an > autonumber column called ID for about 17 years now. It is a good > default. Is quite much a requirement to continue this trend for > tables that you plan to send to SharePoint. > > In fact, if you every up-sized anything to sql server, you also > find that using ID for the PK column works quite well. > > So, keep your designs to the simple PK of ID, and for FK values, > again use a number column. I think you're mixing in two different issues: 1. PK 2. indexes So far as I understand it, because Sharepoint doesn't support multi-field indexes it therefore cannot support composite PKs. So, your suggestion only partway solves the problem, as it provides a replacement PK for the multi-column key. But it doesn't address the indexing issue -- unique indexes on multiple columns are pretty important, don't you think? And the example I gave in another response was of your standard N:N join table, which is made up of two foreign keys that together make the primary key. Adding a surrogate key is not going to help at all, unless you're joining something to the record in the join table (in which case, I would have argued that you should have had the surrogate key in there to begin with, and not because of Sharepoint!). It seems to me that join tables are not supported in Sharepoint. While this is not a terrible problem for where one side is a single-column join (that can be replaced with a multi-value field), if you're joining complex entities, you're out of luck. I guess a table-level data macro could be used to enforce uniqueness, but it sounds expensive in terms of processing. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 20 Nov 2009 15:11 Salad <oil(a)vinegar.com> wrote in news:msqdnXyZM4aOg5vWnZ2dnUVZ_o9i4p2d(a)earthlink.com: > David W. Fenton wrote: > >> Salad <oil(a)vinegar.com> wrote in >> news:MdadnciZR77gP5jWnZ2dnUVZ_gidnZ2d(a)earthlink.com: >> >> >>>Bob Alston wrote: >> >>>>One requirement that the database be in Access 2007 format. >>> >>>Would that be a problem? One can link to a SharePoint table with >>>A2003. >> >> I think you're completely missing the point. Bob was trying to >> test the new publish to Sharepoint feature, where you create an >> ACCDB and can publish it to Sharepoint, where it will run in the >> browser and look nearly identical to the way it looks running in >> Access. There was a humongous thread on this very topic last >> week. >> >> Linking to Sharepoint is not even close to the same thing as the >> new features being offered by A2010 in terms of Sharepoint >> integration. > > I still don't get it. Who cares about the format being a problem > if one can publish an app to the web. Is the problem that one > can't get to the data unless it's in A2010? Either way, who > cares? ??? New features have been added to A2010 that enable this massive new set of capabilities. It is entirely dependent on new features that have been introduced over the course of the development of A2007 and A2010: A2007 - multi-value fields - attachment fields - append-only memos - embedded macros A2010 - table-level data macros - web forms/reports When you put those new A2010 features together with what was already introduced in A2007, you get the capability to publish your Access app to Access services on Sharepoint. But you have to have all the parts, and the most important part (the web forms/reports) are entirely new in A2010. It's all of these things that enable the publishing and tight integration with Sharepoint. It's these new features that make the web version nearly indistinguishable from the Access version. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 20 Nov 2009 17:50 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message > > So far as I understand it, because Sharepoint doesn't support > multi-field indexes it therefore cannot support composite PKs. So, > your suggestion only partway solves the problem, as it provides a > replacement PK for the multi-column key. > > But it doesn't address the indexing issue -- unique indexes on > multiple columns are pretty important, don't you think? Do you mean a compound index like an index based on more then one column, or do you mean several collumns each with an unique index? We have the 2nd case above.. So, you can have many indexes, and they all each be set as unique. You simply don't have indexes that are compound, or the result of more then one column however. So, that's why I gave that possible work around. So, to be clear: for 2010 you can have many indexes. And as many as those columns can be set as unique. We just don't have a compound index ability. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 20 Nov 2009 18:08
"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message \\\ > New features have been added to A2010 that enable this massive new > set of capabilities. > > It is entirely dependent on new features that have been introduced > over the course of the development of A2007 and A2010: > > A2007 > - multi-value fields > - attachment fields > - append-only memos > - embedded macros > > A2010 > - table-level data macros > - web forms/reports > Yes... (thanks for jumping in here..).... Keep in mind, as it stands, I believe they going to keep the format the same for 2007 to 2010. And, right now, if you open a table with triggers in access 2007, you get an message explain that features are present that don't allow you to update the table. So, the ace 2007 is aware of those triggers...and will tell you! I already tested the above. So, access 2007 (sp2) can open the current 2010 accDB files. I believe the policy and goal is things to remain as this beyond the beta release... In other words, if you use a table feature in 2010, access 2007 can open it, but will inform you it can't be updated. So, to add more confusing, I believe the goal here is to allow access 2007 to open the 2010 files. This means I don't think they going to come out with a specific 2010 format as of this time... And, for a database marked as web only, there not a different extension (we have too many already!). I have no idea what happens if I open an 2010 web app in 2007,..hold on..let me try right now.... Oh, now this is cool. I can open the accDB file. And, I even see the objects in the nav pane. I also get a message from 2007 warning about features not supported. The web link given here is VERY cool: http://msdn.microsoft.com/en-us/office/cc907897.aspx Enjoy the above read...it interesting.... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com |