One problem that our customers appear to be running into is checking in projects. We do have a bug that appears to leave projects checked out when you wouldn't expect them to be. But I suspect that in many cases it may be that the architectural changes to 2007 have caused some of this confusion - and the default view of the queue may well hide the true cause of the problem.
So - check out these different scenarios to see if this covers your issues:-
UPDATE: Thanks to Ed Hanna and Brian Kennemer for bringing it to my attention - but it appears that closing Project using the X in the top right can lead to check-in issues. So best practice would be first to save and ensure that any communication with the server has completed (look in the status area after saving) and then using File, Close.
Technorati Tags: Project Server 2007
I had a question from my blog (thanks Alex!) on SQL deadlocks and error messages like the following on a busy server.
System.Data.SqlClient.SqlError: Transaction (Process ID 84) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
You will also see error id 7747 in the application event log.
This can be an issue with systems that are quite stressed and in all cases I have seen relates to the process that selects the queue jobs for processing. It does not break anything as such and no data is lost – but processing of queue jobs is delayed (but as the system is very busy they probably wouldn’t have processed quickly anyway!).
Deadlocks occur when two transactions interact in such a way that one requires a resource that the other has locked, and vice versa. Because neither task can continue until a resource is available and neither resource can be released until a task continues, a deadlock state exists. SQL Server selects one of the transactions as the victim and ends it – and posts the above error. See the SQL Server Books Online for more details.
In Project Server 2007 you can monitor activity using perfmon, and the counters include SQL retries per minute for both the Project and Timesheet queues. You can also modify the queue settings which can reduce the occurrence or behavior of the deadlocks. We don’t have any prescriptive guidance yet on suggested changes, but certainly reducing the number of threads, increasing the polling interval, or increasing the SQL retry intervals would likely reduce the number of deadlocks you see. However, these changes will also reduce the throughput of your queue – particularly when processing light weight jobs. If you see the deadlock behavior at specific time of day only – and want to change queue settings to suit workload you could even use the QueueSystem web service to change the settings (using the SetQueueConfiguration method).
I’m not sure if anyone will really want to micro-manage their queue in this way – or what the overall throughput benefits would be – but the option is there.
Online at http://www.microsoft.com/downloads/details.aspx?FamilyId=2672F6F9-7028-4B30-99A2-18CB1EED1ABE&displaylang=en you can now download the latest SDK with plenty of new content. The online version will also be updated in the next day or so. New topics for this April 2007 release are:-
· XML Schema References for Project (15 topics; includes the ChangeList Schema Reference)
· Changes for Custom Project Guides
· Custom Fields in OLAP Cubes (in the Local and Enterprise Custom Fields topic)
· How to: Generate ChangeXML for Statusing Updates
· Project Server Report Pack (9 topics)
· Walkthrough: Creating a PSI Extension
· Walkthrough: Develop an Impersonation Web Application
Other updates include enumeration descriptions, PSI method permissions, TimesheetDataSet properties, and a VBA sample for Project Deliverables.
The online Windows SharePoint Services 3.0 and MOSS 2007 SDKs will also be updated by the end of April.
Great work Jim and the team!
If you are a regular reader you may remember that the loading of the Microsoft SQL Server 2005 SP2 component "Reporting Services Add-in for Microsoft SharePoint Technologies" broke the OLAP cube builds as it removed a required component when used on an aplication server that was not the SQL Server host too. Well if you load the February update to the SQL Management Objects (rather than the November issue) available as part of the Feature Pack release then this problem is resolved!
Feature Pack available here
Microsoft SQL Server 2005 Service Pack 2 available here
Don't forget (like I did) to load the add-in for SharePoint on your web front ends as well as your app server - or you will see an error as your front end web.config will be referring to a component (RSSharePointSoapProxy) that your web front end knows nothing about.
I had a comment posted by Vince Rothwell of a suggestion for troubleshooting the type of errors described in my last posting and thought it was worth a full posting rather than getting lost in comments. Vince gave me a link to his blog at http://blog.thekid.me.uk/archive/2007/02/15/a-solution-to-quot-an-unexpected-error-has-occurred-quot-in-wss-v3.aspx where he describes making some changes to the web.config file for the application giving the error - so that you get a less generic error message. I tried this on one of my servers where I could "force" some typical errors of this type. Instead of the "unknown error" you get a stack trace which may give good clues to finding the true problem. In my cases one of the issues caused by some unexpected NULL values coming from the database gave a good indication that this was the problem - next step would be tracing where the bad data is. In another case I could see a "GeneralUnhandledException" so still needed to dig deeper. The final case gave me a specific GUID identifying the problem data element. So all in all a good way to troubleshoot these types of errors.
A couple of words of warning though - you probably don't want to do this for a public facing site - and even exposing your users to these types of errors is best avoided. One way to limit the viewing of these errors is to set custom errors to "RemoteOnly" rather than Off - which would then only give the full error details on the server (assuming you can repro on the server). The stack trace errors could tell a potential hacker more about your back-end systems than you would want them to know!
Thanks again to Vince - and please do visit his blog - a great source of excellent information on SharePoint!