WSS & MOSS – workflowProperties.Item.Update causes new versions

29 06 2009

I haven’t really worked with workflow in a document library with versioning turned on yet…until now.

What we found is that each time some metadata of the document was changed using workflowProperties.Item.Update, a new version of the of the file was created!

You could argue that  this is OK and for the majority of implementations this would probably be fine however we needed to find a way around it:

If you do not want to re-version the document when a workflow changes the metadata then you can use the workflowProperties.Item.SystemUpdate method, see the details here –

http://msdn.microsoft.com/en-us/library/ms461526.aspx

The SystemUpdate method writes the data directly to the database and also accepts a boolean flag defining whether or not to increment the version number, perfect!

Hope this helps! 🙂





SharePoint 2010 Screenshots Leaked

23 06 2009

Hi all,

I thought I’d post up a link to an interesting blog post I found, Lee Richardson has posted some leaked/exposed details of SharePoint 2010 – these include a couple of screenshots and the details that the product will include inline list AJAX editing!

I’m sure you are all like me excited about the new product so have a look at his blog post to see more –

http://rapidapplicationdevelopment.blogspot.com/2009/05/secrets-of-sharepoint-2010-exposed-at.html

Thanks Lee! 🙂





Logging to the SharePoint ULS logs programmatically

18 06 2009

When writing SharePoint applications error messages should be handled appropriately, as well as displaying a message to the user it may be useful to log this message to the SharePoint 12 hive error logs. The SharePoint error logs sit in the following location of the server – 12 Hive\LOGS.

To write a message to the log directly from custom code you can use the Microsoft.Office.Server.Diagnostics.PortalLog class, simply reference the Microsoft.Office.Server.dll and use the following method:

PortalLog.LogString(yourerrormessage)

The LogString method accepts a string so just pass in your exception message and your good to go. Additionally the ‘DebugWriteString()’ method works the same way as the above but allows you to specify the level of the item that you are logging (Critical, Error, Information or Verbose).

Hope this helps someone! 🙂





‘Fear’ of the SharePoint Content Databases

12 06 2009

I have recently read a few interesting comments from people on the web regarding SharePoint content databases, it seems almost fear the prospect of delving in to the content databases.

I appreciate that modifying data in the content databases could mean that your warranty/support contract is no longer valid but for reading data I personally find it very helpful. I have created a number of SQL Reporting Services reports that read their data straight from the content databases and often this is a lot quicker than point the report straight at the SharePoint site.

I would be interested to hear peoples comments on this, it almost seems that because SharePoint is designed with a rich front end for the users that the backend databases should not be touched. One thing that is frustrating though is the way that SharePoint stores the data in the AllUserData table, each column in SharePoint is represented by a seemingly random name in the table – e.g. a field called ‘User Name’ could be ‘varchar1’ in the table. The number would increase for each column of that type.

Let me know what you all think…





Issues when installing Timer Job from Feature Receiver

4 06 2009

I am currently working on a custom timer job to provide some basic archiving functionality for one of our SharePoint sites. Whilst doing this I have come across a few problems when you use a feature receiver to install the Timer Job for you, Molnar Tibor has a useful blog post explaining the problems and solutions –

http://geekswithblogs.net/MTex/archive/2008/07/27/124065.aspx

I will explain them here too for clarity:

1.When you active the feature you may receive the following error:

System.Data.SqlClient.SqlException: The EXECUTE permission was denied on the object ‘proc_putObject’, database ‘SharePoint_Config’, schema ‘dbo”

The means that the web app’s application pool account does not have the correct access to the SharePoint Config database. You will need to set the correct permissions in SQL Management Studio – security admin permissions should be ok.

2.After you have completed the above, the code for deleting the timer job will throw an exception –

Access to the path ‘C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\360c4621-fccb-4c2a-9182-b3c75ae80cf3\cache.ini’

In order to solve this you need to give the WSS_WPG account full control on the folder that contains the cache.ini file, in this case ‘360c4621-fccb-4c2a-9182-b3c75ae80cf3’.

Hope this helps! 🙂