SQL Server Agent Job Completes but Stored Procedure Doesn't Run

StackOverflow https://stackoverflow.com/questions/13955249

Question

I have a stored procedure to simply run a series of UPDATE statements on a CRM2011 SQL Server. The goal is to have it run every 30 minutes via a SQL Server Agent job. The stored procedure does not expect any parameters.

I create the job and add a step to call a T-SQL statement "EXEC mystoredprocname". I right click and "Start Job at this Step" and it completes successfully. However, none of the updates are reflected in the database.

If I run "EXEC mystoredprocname" manually in a query line, it executes fine and the database is updated as expected.

This seems like something that should be incredibly simple, so I am not sure where the breakdown in my process is.

Was it helpful?

Solution

As you mention in your comments that your stored procedure uses a filtered view, I'm fairly willing to wager that you are not running the schedule as a user who authenticates via Windows Authentication and also has the correct CRM permissions, because, as has oft been noted, filtered views implement the CRM's Windows-based authentication model.

So I have three suggestions:

  1. Double check to make sure the schedule is running under the Windows account of a CRM user who has the correct read permissions.

  2. Since you're committed to updating the tables directly, the only reason why you'd want to use a filtered view is because it packages the retrieval of the string representations of OptionSets for you. You can instead query the StringMap tables directly and reference the regular views, for which you don't need to be a CRM user to access. You'll notice a speed improvement as well, as filtered views are slowed down by the security checks.

  3. If you're not committed to updating the tables directly, why not rewrite your stored procedure as a small app that you can schedule that will do the updating every 30 minutes? Unless you have a massive delta, this should be the preferred approach. You gain the advantages of the built-in validation model in the CRM web service, and though you lose the benefits of a set-based approach, I think the pros of working with a third-party system outweigh the cons of potential hacks and breaks in the system. If you are not a .NET developer (and even if you are), the CRM SDK has many examples that could help you get started.

Below are some other questions that relate to my points above and may help you.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top