If you cared to peek inside the SQL Server database that SharePoint uses to store Lists, you would realize that all list items are stored in one giant sized table with columns names int1, int2, int3 and so forth. Therefore, many techniques you may have picked up in optimizing your operations with linked tables may be inapplicable and we need to consider new ones. I’ve said it before and I’ll say it again: SharePoint is anything but a true relational database.
There are some key differences between the two we will discuss later in the article.Īs linked tables go, SharePoint Lists are definitely a horse of different color. Therefore, if you know something about them, you’ll also know something about web tables. If you’re using the new web database with Access 2010, the “web tables” are in fact SharePoint Lists by a different name. Now we’ll examine the main object you’ll interact with SharePoint within Access: Lists. In a recent post, I discussed how SharePoint and Access address similar audiences and provide easy solutions to different problems. Note: This is the second part of a three part series, you can find part one here and the third part here.
Custom Quoting and Proposal Sales Force Solution.Amazon API Integration with Microsoft Access.Convert ADP file to ACCDB (regular Access file).Enable Microsoft Access to work from home.Microsoft Access Database Inconsistent State Error.