If somebody like the post and its helpful in your work then, add comments.

Sunday, December 13, 2009

SharePoint Timer Job : Key things while developing

Hi All,


While developing custom job for SharePoint 2007, I had faced many problem. I develop this job as feature in SiteCollection. On the deployment time of the feature for SharePoint job it gives many type of permission issues. Like when we activate the feature, it adds the SharePoint job in the Central Administration->Operation ->SharePoint Job definition.  So, the user (like Domain\User) which have administrator permission also generates the error on deployment time of SharePoint job. It gives following error “'System.Data.SqlClient.SqlException: The EXECUTE permission was denied on the object 'proc_putObject', database 'Intranet_Config', schema 'dbo'” at taskLoggerJob.Update(); code. So after many research and googling I find these following two resolution for the error.

  1. During feature activation I had: 'System.Data.SqlClient.SqlException: The EXECUTE permission was denied on the object 'proc_putObject', database 'Intranet_Config', schema 'dbo''. After doing a profiling on the database, I saw that the SPJobDefinition.Update() code is executed with the web application's application pool account. This account has to have access to the configuration database. I did this by setting the necessary rights in SQL Management Studio by giving to the web application's application pool account EXECUTE permissions on the proc_putClass, proc_putObject, proc_getNewObjects and proc_dropObject stored procedures.

  2. After doing the thing above, the SPJobDefinition.Delete code throws a weird exception: Access to the path 'C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\360c4621-fccb-4c2a-9182-b3c75ae80cf3\cache.ini' is denied. Solution: give full control to the WSS_WPG user on the folder where the cache.ini file is searched.

Find at following link.

Second, issue which I am faced the problem when debugging the solution. When I am attached the solution with OWSTIMER.EXE one the time of debugging the solution, when the error generates in the code and after resolution of the error and rerunning the solution in debug mode. The OWSTIMER.EXE is attached with previous dll of the solution. Means it does not refer the updated dll of the solution. So, to overcome this issue we have to rerun the “Windows SharePoint Timer” service from the services. When you deploy the solution, then we have to restart the service.

No comments:

Post a Comment