You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Tips
How-to
News
Videos
Stories
In the last post, I gave a quick overview of SharePoint, SharePoint lists, and how Access works on SharePoint. In this version, I'll show what happens when you move an Access database to SharePoint.
Access has had a feature to "Upsize to SQL Server" for quite some time, and the "Move to SharePoint" feature in 2007 is very similar. It creates SharePoint lists for all the data, moves the data to those lists, and replaces the local tables in the database with remote tables linked to the newly created lists. The database behaves much like it did before, with some new functionality on the server, and potentially some client features no longer available. The move process is pretty simple, and starts from a local database to be moved.
When the database is moved to the server, some functionality may be lost due to the differences between the SharePoint data store and Access. The Move to SharePoint feature creates a table in the database that lists any alerts and explains why they occur. The user can open this table from the Nav Pane.
Once the application is on SharePoint, the user can look at the lists either through the SharePoint thin views or through the Access rich views. The Access tables now appear in the list of lists on SharePoint. Opening one of those lists displays the data that was in Access.
Since the data is now in SharePoint, it can use SharePoint functionality, so for example deleted items are moved to the Recycle Bin, users can apply workflow rules to the items, and changes to the list are versioned by default.
The Access views appear in the list of views along with the browser views, so linking back to Access is as simple as selecting a view from the dropdown. Clicking on "Open Issues by Category" will automatically bring down the front-end from the server and open that report in Access.
In the next post, I'll talk about taking SharePoint apps offline, and about making the browser version of the applications richer by using the new SharePoint Designer tool.
Comments: (28) Collapse
Stevbe, SharePoint gets worse! When you store data in SharePoint there is no primary key other than the artificial numeric ID, and there is no unique constraints (Unique indexes) for the natural key. Thus there no way to prevent duplicate data! Further, in SharePoint v1 and v2 (and likely v3) when you use the website to create a "list" item (enter data into a table), users can multi-click the Save button creating duplicates. Now we all know how consistent M$ has been with the single-click / double-click UI idiotism. So, users are always real clear as to when to single-click and when to double-click - not. Really, its quite shocking that M$ pushes SharePoint as an "Enterprise" solution when a well known and simple to correct web application problem like users multi-clicking on a Save button has never been corrected. Microsoft calls WSS an enterprise product. What crap - if users can simply and accidentally create many duplicates of an item, then in this respect WSS is like a HTMLv1 Joe website designer product, not ready for prime time.
Sorry I've been absent for a bit (both for posts and comment replies). There has been quite a discussion here about SharePoint, Access's future as a development tool, and the ribbon. Since we've already been through these issues all separately in the comments, the newsgroups, and on other forums, I won't restate all the arguments. Suffice it to say that we believe we've made changes to the app that make Access a better tool for all users and revitalize the product by expanding the number of users who can use it. I understand that not everyone buys our reasoning, and that's fine. We believe the tool is still better for all users - even if the arguments about "MS should have feature A and they built feature B" are true, in our research, the breadth of new tools make developers more productive and end users more successful, full stop. If you don't agree, you have my appologies and can rest in the knowledge that we're planning another big release and are looking at a tremendous amount of innovative work for that one as well. As far as the content of the posts, I'm still following the outline I laid out at the beginning of the year. That means that there are a couple more SharePoint posts to come, then we'll move on to other things. My plan is to cover upsize to SQL or Access backend, Access macros and disabled VBA, the developer extensions, and upgradig to Access 2007. If there are other topics you'd like to see, please post or send me mail, and I'll try to get to them. Thanks, Erik
Mike: WSS is not the same thing as SharePoint, that would be like saying that Jet and Access are the same thing. WSS is just a data store, nothing more, nothing less, I was programming with it back before it was RTM'd with Exchange 2000. Yes, Noticed that the "Lists" feature is never referred to as Tables and in no way has been stated as being relational. I am with you on the idea that both those idea are implied because they are talking about the capability of using it as a data store for Access and it would have been nice to have the details up front. I am always trying to keep in mind that like Eric posted, they have made up their minds on the functionality being introduced or removed. Period. I also try to keep in mind that this is still in beta so in some cases they have not had time or even the final features completely set so may be unable to provide details.
Eric: Sorry if I sounded confrontational, I really do appreciate the information you have been providing us even if I don't always agree with the decisions that have been made. I hope this experiment in continual development blogs does not die because it seems like all you get is flack and the onerous spam posts " great site ... meet me at the poker table". Which leads to an off topic question ... can you folks block post backs that have the words "poker", "alice", or "zoomer" in them? that would trim the auto-email by about 50%. Thanks again,
Steve I think for my current employment, 2007 will not affect me much other than working out the detail of the ribbon which don't seem to really be that difficult, just a bit more time consuming.
"WSS is not the same thing as SharePoint, that would be like saying that Jet and Access are the same thing. WSS is just a data store, nothing more, nothing less, I was programming with it back before it was RTM'd with Exchange 2000. " Hmmm. WSS = Windows SharePoint Services = SharePoint v2/v3
STS = SharePoint Team Services = SharePoint v1 "WSS is just a data store" I suppose that Access 07 is not a database application anymore also...
Eric, there are exactly ZERO discussions about how to modify the "Office File Menu" - the big round button. This has NOT be covered in this blog - or Jensen's - or anywhere. In Access 2007 can the items on this menu be removed/added/changed through VB? For example, can we remove the "Access Settings", New, Open, Save As, etc. I would really like an answer to this!
Erik, I answered my question. Yes, you can modify the "office button" FULLY. This is good news for the HelpDesk… Now if I can just get an event to fire when a ribbon menu TAB is clicked. This will at least allow existing 1024x768 forms to work if the ribbon is set to auto hide - not ideal, a clunky/distracting menu flash actually, but it removes an impediment to Access 07 use by hundreds of users with 1024x768 screens. An alternative is to have the main application objects (that were accessible via a nice slim custom tool bar) accessible via large garish buttons on a ribbon or clumped up buttons or something ribbon-fishy. Mike
Mike: "WSS is just a data store" Yes ... Web Storage System was introduced with Exhange 2000 not with SharePoint (which was code named Tahoe). Take a look at an Exchange 2000 server, you will see a mapped drive "M". This is a virtual drive that you can use to read/write files into WSS directly from Windows Explorer. SharePoint is just another FE into WSS. You can read/write to WSS without using SharePoint at all by using file system code, ExIFS and even with ADO. it is a database management system, it does not store the data in and of itself, that is why we have the option to use jet, newjet, excel, text, sharepoint etc. as data sources. I am still experimenting with ribbon options myself and also dislike the *playschool* button size but have not come up with a good use of the extra space if I do use small buttons. Steve
I finally got to updating to the nearly half a gig "2007 Microsoft Office system Beta 2 Technical Refresh". I could not find any info as to what was fixed or changed for Access in this release. Does anyone have a clue on this? One thing that I noticed was NOT fixed was the "auto repeat" capability on the navigation buttons (i.e. the ability to quickly scroll through records when the forward or back buttons are pressed). I reported this months ago. I was hoping that there would be several new "color schemes", or a way to make forms have a classic Windows style. Will this ever be possible?
Stevbe, Ok, now I understand your confusion! The acronym “WSS” was also used for the “Web Storage System”, an Exchange 2000 and SharePoint Portal Server 2001 (SPS) storage tech that now is defunct. Exchange now calls it “Exchange Storage”. There is no “M:” drive in Exchange 2003. Windows SharePoint Services, SharePoint Portal Server 2003, the new Office SharePoint Server (MOSS) do not use the old Exchange Web Storage System. The future of Web Storage System in Exchange is murky. Clear as M$ mud? To say this another way, Windows SharePoint Services (WSS) that M$ linked Access 07 to has nothing to do with the old Web Storage System. WSS uses SQL Server or MSDE/Express as a storage platform in a funky SharePoint kind of way (basically everything is stored in three tables). You did make me think, although. From the stand point of Access, it makes no sense to story anything on SharePoint. But from the Standpoint of SharePoint, it’s good to have something as powerful as Access to handle data massaging. So for example if a SharePoint “list” (that is SharePoint lingo for a pseudo table), contains a survey or URLs, contacts, etc, you can at least get at this data and manipulate it allot easer in Access. This is one case where it makes sense to link Access to SharePoint. Mike
OMG ... thanks for correcting me ... it has been a while (obviously) since I worked with Original WSS ... never touched the new Coke :-) Why use the same TLA ... with only 19683 (3^3?) available they need to start conserving resources ... or is this kind of like the confusin being sown by mashing WinFX and .NET 2.0 together and calling it .Net 3.0? I don't ever plan on storing anything in SharePoint directly, hey ... I read the details, it really is good at indexing but you are are wasting time and space by not just pointing it at your file servers. OK ... enough rant ... I have not got B2TR on my PC yet but am planning on it this weekend for more ribbon experiments. Steve
Access 2003 already had some WSS 2.0 integration capabilities: it could link, import and export lists, edit data, create reports based on WSS data, etc. Now Access + WSS integration is said to be a "brand new feature" and, even more, the main reason to upgrade do A2007. It's a nice feature to have and I consider Access an excellent front-end to WSS data, but I don't believe I'll see or work with Access + WSS apps because 99% of the Access relies on desktop databases. I want to see what was done for developers: improvements in object models? Tools for code-generation? Mouse wheel in VBE is fine, but it should be on since Access 2k or XP. Report and form design capabilities are one of the main benefits for developers.
What is it going to take to get microsoft to add an auto scheduling function to MS Access. Please try to look at it from the users side. To schedule reports in MS Access would be a revolutionary tool. Please try to help us.
Comments: (loading) Collapse