Access 2010 beta - Publish to Sharepoint
in [Help]
|
Prev: Keeping A Citrix Session Alive?
Next: Help in A2010
From: Salad on 19 Nov 2009 15:22 Bob Alston wrote: > Salad wrote: > >> Bob Alston wrote: >> >>> Salad wrote: >>> >>>> Bob Alston wrote: >>>> >>>>> Ok I got the Access 2010 beta. found I must have the database in >>>>> Access 2007 format in order to be able to see the share to >>>>> Sharepoint option and thereby get to the validation routine to see >>>>> if it is compatible with Sharepoint. It wasn't. >>>> >>>> >>>> >>>> Thanks Bob for posting the Offic 2010 Dl site. >>>> >>>> Could you provide further clafification on your statement above. >>>> What do you mean...compatible with sharepoint? Or see the share? >>>> >>> >>> To publish an Access database to Sharepoint, there are requirements >>> that must be met. >>> >>> One requirement that the database be in Access 2007 format. >> >> >> Would that be a problem? One can link to a SharePoint table with A2003. >> >>> >>> Another is that certain things are not allowed, such as the items I >>> mentioned in my original posting. >> >> >> But the first and third appeared to be extremely minor. I didn't >> understand the relationships issue you mentioned. Are the >> relationships set in the Sharepoint site or in the Access app or >> neither? Is there a new way to define relationships? >> >> >>> >>> HTH >>> >>> Bob > > I really cannot yet answer your questions. I can just post questions I > have. > > In using Access 2010 beta, I had to have the database in Access 2007 > format for the "publish to Sharepoint" option to become active. I have > no idea how this works in older versions of Access. > > Bob But isn't that A-OK? We're talking about publishing an app to the web. That would include forms and reports. Not just back end data. Albert mentioned there'd be some adjustments. I guess you came across some.
From: David W. Fenton on 19 Nov 2009 22:11 Bob Alston <bobalston9(a)yahoo.com> wrote in news:55hNm.30444$X01.19593(a)newsfe07.iad: > One requirement that the database be in Access 2007 format. That is, ACCDB. MDB is also an Access 2007 format. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 19 Nov 2009 22:10 Salad <oil(a)vinegar.com> wrote in news:SYqdnT0fcu8aBJjWnZ2dnUVZ_uSdnZ2d(a)earthlink.com: > When is there a need for a composite index? N:N join table with two columns, where each is the PK of the tables being joined -- unique PK on two fields. This is essential for any proper N:N join table. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 19 Nov 2009 22:03 "Bob Alston" <bobalston9(a)yahoo.com> wrote in message news:pYfNm.44381$de6.31863(a)newsfe21.iad... > Ok I got the Access 2010 beta. found I must have the database in Access > 2007 format in order to be able to see the share to Sharepoint option and > thereby get to the validation routine to see if it is compatible with > Sharepoint. It wasn't. We don't see a 2010 format here. So, taking a BIG stab at this, obviously the 2007 and 2010 format will be the same or it not been changed for beta. I see 2003, and then I see the current format. So, as it stands now, the "latest" format is 2007... I think in our computer industry, since about near day one, I quite sure that new features as a general rule always relied on the newest file formats. I mean, you can't use older formats of access files and use the multi-value fields that we received in 2007. So, this again is going to be no different, then what, about the last 20 years of our computer industry? So, for excel, if you use new features, they rarely will be backwards available in previous versions. so, for Word, if you use new features, they rarely will be backwards available in pervious venison. And, dbaseII could not open dbaseIII files...and...(well, you get the idea here). So for access, if you use new features, then one would not be surprised that you need to use the latest format. I would expect this trend follows the experience we seen for every product in the last 20 years of our industry... > > Three types of errors: > > Fields with characters not allowed (: ? $ ........) I have never ever used any strange characters in fields for at least 10 years now. I think once used #, but really, no spaces, and no symbols is something that been preached by long time regulars here likely since the inception of this newsgroup. Now you learning why we preach such things. You do realize that even sql server does not support spaces in field names? So, no junk, and no spaces in field names is a great programming practice that served me very well in the computer industry. > Anyone who has been testing in the earlier test have suggestions for how > to most easily fix these? Well, for field names, simply get rid of the garbage characters you have, and while you at it, adopt a policy of no spaces in field names. > > Cannot use composite indexes Correct. You can certainly set/create an index on each column. From a performance point of view, this should not hurt in most cases. However, if you are using two columns, and an unique index on that column, then you have to forego this feature. Another workaround is to use a trigger to fill out a column that is the concatenation of the two values and place a unique index on this column. eg: SalesKey = [SalesRep] & "*" [AccountNumber] So, in the above we take the sales rep, and the account number they been assigned to. (only one rep can be assigned to a accountnumber), the above will create a unique key column. We used this trick for years for PC database systems like Revelation (remember that from the 80's!), and I also used that trick for systems like IBM's universe and d3 (tiger logic). If you followed the other thread, there was link to limitations of SharePoint lists. Some suggestions: 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. Keep in mind that you must create a blank web database and then import objects in for the checker to really work its magic. Note that all VBA forms etc WILL pass the web checker since they are in fact by-passed during the checking process. The reason for this is of course forms with VBA are permitted in these applications. You will CLEARLY see what forms are marked/set as web as opposed to client forms (no globe icon in the nav pane for client objects). VBA client forms are permitted and they simply don't publish to the web (so, they don't show up in the compatibility checker at all either...they are skipped). Once you have web tables, then you will quickly find out that to setup relationships, you use the lookup wizard. If you need relations diagrams, you have to use the query builder. Unfortunately for SharePoint tables, they could not build a relationships window editor. (it was a feature the access team wanted, but budgets + time means it could not make this cut). Remember, after you published, changes + edits to table designs are permitted, but the tables now reside on SharePoint. At least we don't have to open the table (list) on the SharePoint site to make the changes. I mean, with any odbc server you use with access such as MySql, ms-sql, oracle etc, you have to go the server side to make tables changes. In access, we can add/delete, setup indexes, and setup relations all from the ms-access client all the while the tables are on SharePoint. So, at least we can modify server tables from inside of ms-access and not be forced to go to the SharePoint site. So, at least we have this client table change ability, but unfortunately we don't have the relationships window to do this for us.... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 19 Nov 2009 22:13
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. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |