I'm new to Sharepoint and I'm currently maintaining an established solution which has a bug. Unfortunately I cannot solve the Problem. I get an SPException with ErrorCode 2130575305 in the ItemAdded event when I try to use the properties.ListItem.Update() Method.
It seems like there is a Problem when updating a item shortly after it is updated?
I tried everything I found on the Internet, from using the "ItemAdding" method over allowunsafeupdates to disableeventfiring, but nothing worked, now I ran out of steam
A little piece of program code:
SPListitem itm = list.GetItems(query).Add();
// all single line of text
itm["property"] = anotheritem["property" + "something" + itm["property"];
itm.Update();
and afterward in the overridden ItemAdded:
SPListItem itm = properties.ListItem;
itm["anotherproperty"] = "something different";
itm.Update(); // <- this throws the error
The Original Error Message is in German so it won't help you much, but its saying something along "SPException, please press back in your browser and try again", which isn't of any help anyways.
Also, I can't use try catch in code as it seems to be some sort of web exception?
Sorry x0n, I couldn't try your answer yesterday.
it doesn't work, unfortunately, there is no list in properties, only a listid, and even if I know which list calls the itemadded event and navigate to it through lists["listname"].getitembyid(properties.listitem.id) it won't work.
isn't "grapping a fresh copy" exactly what i did by writing splistitem itm = properties.listitem; already?
Is there a way to "release" the item on the beginning of the itemAdded and reuse it later?
public override void ItemAdded(SPItemEventProperties properties)
{
SPListItem itm = properties.ListItem;
itm["somefield"] = "sometext";
itm.Update(); // <- error, itm.SystemUpdate() throws the same error btw.
base.ItemAdded(properties);
}
I also read the help on msdn, it only tells me the error but not how to handle it, so it wasn't much helpful.
About brian's answer: if itemadded already is the synchronous call there shouldn't be a problem?
When you receive error codes the best resource is MSDN or google. - http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.client.listitem.update.aspx
The error code means the field is read only, which could mean many things. This could be due to permissions of the executing account or a simple race condition.
SharePoint essentially queues up a lot of changes and therefore you can certainly run into timing issues between the different executing threads. If you are changing an item in a sync event(adding) and then again in the async(added) event I would strongly lean towards rethinking the logic of what you are trying to actually do.
Related
I'm currently fighting with using an XMLSerializer to execute XSD validation and collect the validation errors in the files. The task is the validation of the file, based on custom XSD-s containing valueset information, presence information etc.
My problem is the following: when using the XMLReader it stops at the first error, if we attach a listener to the ValidationEvents of the reader (through XMLReaderSettings). So I simply catch the exception where I log the error. So far everything is fine, the problems start to appear after logging the exception. Right after that the XMLReader goes to the end tag of the failed field, but I cannot validate the next field due to an unexplained exception.
To put it in practice, here's my code where I catch the exception:
private bool TryDeserialize(XmlSerializer ser, XmlReader read,out object item)
{
string Itemname = read.Name;
XmlReader read2 = read.ReadSubtree();
try
{
item= ser.Deserialize(read2);
return true;
}
catch (Exception e)
{
_ErrorList.Add("XSD error at " + Itemname + ": " + e.InnerException.Message);
item = null;
return false;
}
}
This routine works well, but what follows is problematic. Assume I pass the following XML snippet to this code:
<a>2885</a>
<b>ABC</b>
<c>5</c>
Assume that 'b' may not have 'ABC' as a value, so I get an XSD error. At the end of this, the xmlreader will be at
'EndElement, Name=b'
from which I simply cannot move unless I get an exception. If I do xmlreader.read, then I get the following exception (cut the namespace here):
"e = {"The element 'urn:iso:.....b' cannot contain child element 'urn:iso:.....:c' because the parent element's content model is text only."}"
After this the xmlreader is at 'Element, Name=c', so it seems good, but when trying to deserialize it with the code above, I get the following exception:
'_message = "The transition from the 'ValidateElement' method to the 'ValidateText' method is not allowed."'
I don't really see how I may go over it. I tried without a second reader reading the subtree, but I have the same problem. Please suggest me something, I really am stuck. Thanks a lot in advance!
Greets
You may have to consider the following things:
In general, it is not always possible to "collect" all the errors, simply because validating parsers are free to abandon the validation process when certain types of errors occur, particularly those that put the validator in a state where it can't reliably recover. For e.g., a validator may still continue after running into a constraining facet violation for a simple type, but it'll skip a whole section if it runs in unexpected content.
Unlike parsing into a DOM, where the loading of a DOM is not affected by a validating reader failing validation, deserializing into an object is (or at least should be) totally different: DOM is about being well formed; deserializing, i.e. strong typing is about being valid.
Intuitively I would think that if you get a validation error, what is the point in continuing with the deserialization, and further validation?
Try validating your XML independent of deserialization. If indeed you get more errors flagged with this approach, then the above should explain why. If not, then you're chasing something else.
I was happy enough to have inherited a terribly written SharePoint project.
Apparently, the original developer was a big fan of reusable code (30% of code is reused across 20 projects without using any libraries—guess how?).
I would often find his code calling some Common.OpenWeb method to retrieve SPWeb object for operating SharePoint stuff. Most of this function's incarnations look exactly the same:
public SPWeb OpenWeb()
{
String strSiteUrl = ConfigurationManager.AppSettings["SiteUrl"].ToString();
SPSite site = null;
SPWeb web = null;
try
{
using (site = new SPSite(strSiteUrl))
{
using (web = site.OpenWeb())
{
return web;
}
}
}
catch (Exception ex)
{
LogEvent("Error occured in OpenWeb : " + ex.Message, EventLogEntryType.Error);
}
return web;
}
And now I'm really worried.
How come this works in production? This method always returns a disposed object, right?
How unstable is it, exactly?
UPDATE:
This method is used in the following fashion:
oWeb = objCommon.OpenWeb();
SPList list = oWeb.Lists["List name"];
SPListItem itemToAdd = list.Items.Add();
itemToAdd["Some field"] = "Some value";
oWeb.AllowUnsafeUpdates = true;
itemToAdd.Update();
oWeb.AllowUnsafeUpdates = false;
I omitted the swallowing try-catch for brevity.
This code inserts value into the list! This is a write operation, I'm pretty sure Request property is being used for this. Then how can it work?
First, the short answer: that method indeed returns a disposed object. An object should not be used after being disposed, because it's no longer in a reliable state, and any further operation performed on that object should (theoretically) throw an ObjectDisposedException.
Now, after digging a little, SharePoint objects don't seem to follow that rule. Not only does SPWeb never throw ObjectDisposedException after being disposed, but it actually tests for that case in its Request property and rebuilds a valid SPRequest from its internal state if it has been disposed.
It seems that at least SPWeb was designed to be fully functional even in a disposed state. Why, I don't know. Maybe it's for accommodating client code like the one you're working on. Maybe it's some kind of complicated optimization I can't possibly understand.
That said, I'd suggest you don't rely on that behavior, because it might change in the future (even though, given Microsoft's policy on bug-for-bug backwards compatibility, it might not).
And of course, you will still leak the new SPRequest instance, which can be quite costly. Never, ever, use a disposed object, even if SharePoint lets you get away with it.
I've got a web part that accesses the SP object model, packaged in an assembly which is signed and deployed to the GAC. The web.config is set for "Full" trust, and yet my web part throws a SecurityException. The offending lines of code:
SPSecurity.RunWithElevatedPrivileges(new SPSecurity.CodeToRunElevated(() =>
{
foreach (SPGroup g in user.Groups)
{
identity += String.Format(",'{0}'", g.Name.ToLowerInvariant().Replace(#"\", #"\\"));
}
}));
It appears that the exception is thrown when RunWithElevatedPrivileges is called (in other words, my delegate doesn't execute at all). Any ideas? I'm completely bewildered at this point.
update: here's what the code looked like before I wrapped it in the RunWithElevatedPrivileges method:
public MyWebPart()
{
context = new MyProject.Data.MyDataContext(ConfigurationManager.ConnectionStrings["MyDB"].ConnectionString);
SPUser user = SPContext.Current.Web.CurrentUser;
identity = String.Format("'{0}'", user.LoginName.ToLowerInvariant().Replace(#"\", #"\\"));
foreach (SPGroup g in user.Groups)
{
identity += String.Format(",'{0}'", g.Name.ToLowerInvariant().Replace(#"\", #"\\"));
}
identity = '[' + identity + ']';
}
And the exception:
System.Security.SecurityException occurred
Message="Request failed."
Source="Microsoft.SharePoint"
StackTrace:
at Microsoft.SharePoint.SPBaseCollection.System.Collections.IEnumerable.GetEnumerator()
at MyProject.MyWebPart..ctor()
InnerException:
Based on the highlight provided by the exception helper, it looks like the attempted access of the SPUser.Groups property is the problem: user.Groups.
What's got me really confused is that this exact code was working fine two days ago, but I had some other problems with the farm and basically had to rebuild it. After getting everything else back up again, I went and tried to add this web part to a page and this problem manifested itself. I tried wrapping the code in the RunWithElevatedPrivileges wrapper to see if I could isolate exactly the offending bit, but it looks like anything that touches the SP oject model causes the exception, including the RunWithElevatedPrivileges method.
update2: I still don't know the real reason this was failing, but it was happening when I was trying to add the web part. After setting breakpoints in the debugger, I realized that the constructor was being called twice; the first time, it all worked exactly as expected, but the second time was when the exception was being thrown. I still have no idea why. I found two ways around this: move the offending code out of the constructor into a later point in the lifecycle of the web part, or comment out the code to add the web part, then uncomment it and redeploy.
Apparently, the reason this "worked 3 days ago" was because I had added my web part to a page a long time ago, and then added the above code to the constructor. Since the web part was already added, I never saw any problems. Later, when I recently had to rebuild the site and add the web part to the page again, this problem manifested itself. So technically, it didn't "work" before, I just wasn't doing the thing that made it misbehave.
Anyway, like I said - I still don't know the true cause of the exception, so answers along those lines are still welcome.
The problem could occur if you try to work with SharePoint objects which were created outside of the RunWithElevatedPrivileges() method, and therefore still hold their old security context. In your case you use a SPUser object which was not created within the RunWithElevatedPrivileges() method.
To work around, you should create the object you want to work with within the delegate. Safe Ids or URLs outside of the delegate, to use them for recreating the objects. E.g.: safe the URL or ID of a SPSite object and use it to create it again within the delegate.
public void Demo()
{
string siteURL = SPContext.Current.Site.Url;
SPSecurity.RunWithElevatedPrivileges(delegate(){
using (SPSite safeSite = new SPSite(siteURL))
{
// place your code here ...
}
});
}
Perhaps you could post the stack trace so we can get some more information.
I'm looking for articles, forum or blog posts dealing with SharePoint and thread safety? I'm quite sure there are some special aspects regarding thread safety that have to be considered when working with the SharePoint object model.
Actually I didn't find many information about this, yet.
So I'm looking forward to your answers.
Bye,
Flo
There are much worse pitfalls in the SharePoint OM than just plain old thread safety. Pay particular attention to working with objects retrieved from properties. You should always keep a pointer to an object while you work on it; example:
var list = web.List["MyList"]
list.Items[0]["Field1"] = "foo"
list.Items[0]["Field2"] = "bar"
list.Items[0].Update() // nothing is updated!
You might expect Field1 and Field2 to be updated by the final Update() call, but nope. Each time you use the indexer, a NEW reference to the SPListItem is returned.
Correct way:
SPListItem item = list.Items[0]
item["Field1"] = "foo"
item["Field2"] = "bar"
item.Update() // updated!
Just a start. Also google for pitfalls around the IDisposabe/Dispose pattern.
-Oisin
There is one issue that I often run into: when writing your own list item receivers, you need to be aware of the fact that some of the events fire asynchronously, e.g. ItemAdded() which means your code could be running in multiple threads at the same time.
So after doing some more googling and searching on the web and testing, it seems as if you don't have to care about thread-safety that much when using the MOSS object model because you're always working with non-static and unique instances.
Furthermore an exception is thrown when a object e.g. a SPWeb was altered and saved by calling the Update() method before you saved your changes (also calling the Update() method) even though you got your object first.
In the following example the instruction web11.Update() will throw an exception telling you that the SPWeb represented through the object web12 was altered meanwhile.
SPSite siteCol1 = new SPSite("http://localhost");
SPWeb web11 = siteCol1.OpenWeb();
SPWeb web12 = siteCol1.OpenWeb();
web12.Title = "web12";
web12.Update();
web11.Title = "web11";
web11.Update();
So the thready-safety seems to be handled by the object model itself. Of course you have to handle the exceptions that might be thrown due to race conditions.
What im wondering how to do is when someone edits a list item and it goes through my event code that is fired when a change is made and save is hit, i dont want anyone to be able to edit that list item itself while its still processnig that request. So i was wondering if while in that event i can disable the individual item from being edited by someone else untill it is done doing what it is doing.
Not sure if I understand exactly what you are want.
Try adding a field, hidden if you like, to the list or content type to use as a flag. When you enter your event code, make sure you check the flag first and if not set, set it and do your stuff. After you have done your stuff, unset the flag.
Here is some code to illustrate. Note that I have used a column named "updating". You can use the properties of the SPListItem as well if you do not care to add a column.
Oh, and don't forget to call DisableEventFiring before you to SPListItem.Update and then EnableEventFiring() afterwards. For get this and you will have a very nasty infinite loop on your hands.
.b
public override void ItemAdding(SPItemEventProperties properties)
{
if (properties.ListItem["updating"].ToString() == "updating")
{
properties.Cancel = true;
properties.ErrorMessage = "Item is currently updating, please try again later";
}
else
{
properties.ListItem["updating"] = "updating";
this.DisableEventFiring();
properties.ListItem.Update();
this.EnableEventFiring();
// do your stuff
properties.ListItem["updating"] = "";
this.DisableEventFiring();
properties.ListItem.Update();
this.EnableEventFiring();
}
}
I have no doubt that Bjørns solution will work but you have to be very carefull when implementing it.
Pls. remember at your updating method should include a "finally" that resets the flag, no matter which exception gets thrown, other wise your list will be locked down for ever :-(