Bulk Deletes on SharePoint

Recently I had a requirement to delete a lot of items from SharePoint lists. I initially tried doing this via for loops and foreach loops. This took a long time. Then I found this article:

http://coffeeandsharepoint.blogspot.co.uk/2012/04/deleting-items-on-list-using.html

This really helped and it is surprising to note the increase in speed, however one thing to note is that I’m not certain whether this would trigger any event receivers attached to a SharePoint list in fact I’m pretty positive it wouldn’t. I’ll talk about this in another post and why that is of interest to me, right now it’s worth noting that the increase in speed is really something and has meant a slow delete hogging memory has changed into something a lot sleeker and quicker.

EDIT

I was wrong. It does appear to trigger the event receivers attached to the SharePoint list. Maybe that’s because my code calls list.Update and this detects the deleted items.

Further thoughts on the Big Ball of Mud

In a previous post about the Big Ball of Mud I talked about how we’ve gone about splitting it down into smaller chunks. Sometimes in order to change something you have to make a start. It doesn’t matter if it is the right place or it turns out to be the wrong place the important thing is to make that start. That’s what we did, and with hindsight we made some pretty good divisions.

Now, we can start working on each project. One of the projects held all the code working with SharePoint. One of the goals of our project is to be able to move away from using SharePoint but we don’t have the luxury of writing a new product from scratch. Also I think such a move would be doomed. Better to make natural organic changes on a living working code-base rather than some gleaming theoretical model that isn’t making you any money.

I’ve not really explained that quite well but there is a debate over ‘Revolution’ versus ‘Evolution’ with regards to software. Do you completely scrap something and start again? Or do you work with what you have gradually pushing it towards what you want it to be? There’s pros and cons for both.

Back to the SharePoint project. One of the good things about moving all the SharePoint stuff into one project is that I can concentrate solely on it without worrying about how it’s affecting other parts ot our solution.

It’s all a bit slow going at the moment but the process is moving along.

A Great Big Ball of Mud

The software behind our web services can be described as a big ball of mud with SharePoint wrapped up in it. Actually, I almost typed wrapped wrongly. Warped might also be a perfectly good way of describing SharePoint’s role.

When I first started at my current firm I wasn’t a fan of SharePoint. The person who I thought was going to train me, told me nothing and just cleared off as soon as he could. My current view is that there are lots of good features with SharePoint and in the right context it’s very powerful and can be a fantastic tool. That said it’s not needed for what we do.

I’ve gone off on a tangent. What I really wanted to write about was the process of splitting the big ball of mud into smaller components. I saw this done at a previous company but wasn’t part of the process. Now, I am. It’s rather interesting to tease apart all the tightly coupled classes and processes but a slow task.

Right now all we’ve done is identify which methods and processes serve which class of customer and separate them. We’ve also separated out a business layer. It could well be that this isn’t the final version of the software, but as a first pass it does the job. I’ve rather likened the process to tidying up a great big mess. The very first thing you do is make piles, impose some sort of order so that the whole great big mess doesn’t look quite so daunting. So, you make smaller piles of mess! Break it down into more manageable bits of work. That’s the stage we’re currently at.

The Joy of SharePoint

I have to work with SharePoint. It’s not something I would have chosen to do, and I don’t think SharePoint is a particularly bad product. It’s just unsuitable for what my company needs. If SharePoint was an employee you wouldn’t sack him but you would want to look at areas where his skills would be put to better use. He’s enthusiastic and has some great ideas, he’s just wasted in his current position.

One of the more frustrating things I find with SharePoint is that I’ve started out knowing nothing about it. Everything I’ve learned has been the hard way. That can be a good thing. It can be character building or soul destroying. It can be both.

One of my current tasks at work is to set up a server with SharePoint 2007 on it; and one of the goals is to access SharePoint on this server via a URL that isn’t http://localhost. For arguments sake: http://myallnewSharePointSite. Now, last week I installed SharePoint 2007 with service pack 1 I think. Got it pointing to a database server (which I’m also setting up) and added myallnewSharePointSite to the hosts file. Could I access the site? No. I kept getting prompted to login and even though I was the administrator who had set everything up I could not get past the login prompt. What made things more curious was that if I added http://myallnewSharePointSite to my PC’s host file pointing at the server’s IP address I could log in.

What saved the day for me was a colleague at work who had experienced the same problem. He sent me this link:

http://support.microsoft.com/kb/926642

I’m posting this article in the hope that it may just help someone else.