CRM2011SQLServerで一連のUPDATEステートメントを実行するだけのストアドプロシージャがあります。目標は、SQLServerエージェントジョブを介して30分ごとに実行することです。ストアドプロシージャはパラメータを想定していません。
ジョブを作成し、T-SQLステートメント「EXECmystoredprocname」を呼び出すステップを追加します。右クリックして「このステップでジョブを開始」すると、正常に完了します。ただし、更新はデータベースに反映されません。
クエリ行で「EXECmystoredprocname」を手動で実行すると、正常に実行され、データベースが期待どおりに更新されます。
これは信じられないほど単純なはずのように思われるので、私のプロセスの内訳がどこにあるのかわかりません。
コメントで、ストアド プロシージャがフィルター処理されたビューを使用していると述べたように、Windows 認証を介して認証し、適切な CRM アクセス許可も持っているユーザーとしてスケジュールを実行していないことにかなり賭けたいと思います。フィルター ビューは、CRM の Windows ベースの認証モデルを実装していることに注意してください。
そこで、次の 3 つの提案があります。
正しい読み取り権限を持つ CRM ユーザーの Windows アカウントでスケジュールが実行されていることを再確認してください。
テーブルを直接更新することに専念しているため、フィルター処理されたビューを使用する唯一の理由は、OptionSets の文字列表現の取得がパッケージ化されているためです。代わりに、テーブルを直接クエリしStringMapて通常のビューを参照できます。このビューにアクセスするために CRM ユーザーである必要はありません。フィルタリングされたビューはセキュリティ チェックによって速度が低下するため、速度も向上します。
テーブルを直接更新するつもりがない場合は、ストアド プロシージャを、30 分ごとに更新を行うスケジュール可能な小さなアプリとして書き直してみてはどうでしょうか。大規模なデルタがない限り、これが推奨されるアプローチです。CRM Web サービスに組み込まれている検証モデルの利点が得られます。また、セットベースのアプローチの利点は失われますが、サードパーティ システムを使用する利点は、潜在的なハッキングや破損の欠点を上回ると思います。システムで。.NET 開発者でなくても (たとえそうであっても)、CRM SDK には、開発を始めるのに役立つ多くの例があります。
以下は、上記の私のポイントに関連し、あなたを助けるかもしれないいくつかの他の質問です.