Showing posts with label SharePoint. Show all posts
Showing posts with label SharePoint. Show all posts

Friday, April 15, 2011

SharePoint: The List That is Referenced Here no Longer Exists

While updating list items in a SharePoint list using the SharePoint web service API and specifically through calling
UpdateListItems method you may get everything setup correctly (authentication, authorization, retrieving the list using GetListItems etc.) but when you attempt to update the list using the API your updates are not reflected in the list and when poking around the returned object from UpdateListItems you'll notice it contains the detailed error message "The list that is referenced here no longer exists."

If that's the case make sure you are referencing the correct subsite and not the main site when you create the web reference to Lists.asmx web service. Alternatively you could set the Url property programmetically.

Here is an example:

If your site URL is http://my_share_point_site, the list.asmx can be found at http://my_share_point_site/sites/main/_vti_bin/lists.asmx?WSDL and you could use that URL to reference the API and some things might work. When you attempt to update a list found under some sub_site, your updates will silently fail. You have to reference http://my_share_point_site/sites/main/sub_site/_vti_bin/lists.asmx?WSDL for updates to your.

Some code:

string fieldName = "SomeListFieldToUpdate";
 SPLists.Lists listService = new Lists();
 listService.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
 listService.Url = "http://my_share_point_site/sites/main/sub_site/_vti_bin/lists.asmx?WSDL";
 /* setting Url not required except you referenced a different sub_site or the main site when 
 you created your web reference to Lists.asmx */
 XmlDocument batchDoc = new XmlDocument();
 XmlElement batchElement = batchDoc.CreateElement("Batch", "http://schemas.microsoft.com/sharepoint/soap/");
 batchElement.SetAttribute("OnError", "Continue");
 batchElement.SetAttribute("ListVersion", "21");
 batchElement.SetAttribute("ViewName", editListViewGUID);
 string xml = string.Format(@"        
   {0}        
   {2}
   ", ID, fieldName, fieldValue);
 batchElement.InnerXml = xml;
 var result = listService.UpdateListItems(listGUID, batchElement);
 int.TryParse(result.FirstChild.FirstChild.InnerText, out errorCode);
 return errorCode;

Monday, December 6, 2010

HTTP 401.1 When Visiting an IIS-hosted Site from the Hosting Server

This is tested on Windows 2003 sp2. The conditions:

The Problem:

  • You create a web site on IIS 6 and give the website a host header value, say, somewebapp
  • You create a dns entry of type A pointing to the IP address of the machine hosting the IIS server that's hosting your application
  • You try to visit the web app on the hosting server using the host header value somewebapp and you're prompted to enter a username and password and after entering a valid username & password, you're greeted with HTTP 401.1 Access is Denied error message. Note that if you visit the same app using the same alias from other machines, there is no problem. 
This issue did not bother me until I found out the search function on the SharePoint 3.0 server is not working. It turned out that these two issues are related. The search service on SharePoint does not work because the indexing services cannot crawl the site(s) if both the site and the indexing service are hosted on the same server. Basically, the indexing service receives the same 401.1 error you receive when visiting your apps. You may also notice that numerous warning events are logged on your windows server that's hosting the SharePoint service. These events are under 'Gatherer' category and some look like
The start address <sts3://...> cannot be crawled 
Context: Application 'Search index file on the search server', Catalog 'Search'
Details:
Access is denied.
 The Solution:


 To fix this Microsoft recommends disabling loopback check as detailed here http://support.microsoft.com/kb/896861 

The interesting thing is that if you go back to your DNS record and delete the Host A type record you created for your app and replace it with a CNAME record pointing to the name of the server and not the IP address, the problem disappears after some time after the DNS changes take effect. I tested this with some IIS apps but I did not test in isolation in the case of the SharePoint service to say for sure that changing from Host A to CNAME fixes the problem.