4

スケジュールに従って基本的なクエリを実行するだけの SQL エージェント ジョブがあります。表示されたクエリに基づいて情報を更新します。

USE DB
DECLARE @startDate AS DATETIME
DECLARE @endDate AS DATETIME
DECLARE @rcount AS VARCHAR(10)
SET @startDate = CAST(CONVERT(VARCHAR(10),GETDATE(),112) AS DATETIME) 
SET @endDate = CAST(CONVERT(VARCHAR(10),GETDATE(),112) AS DATETIME) 
--*********************************************************
-- *Run Query
--*********************************************************
UPDATE Table1
SET Table1.field1 = 'ZPR' +  Left(Table1.field1,6),
    Table1.field2 = '0',
    Table1.field3 = '0' 
WHERE  Table1.GUID IN (SELECT GUID FROM Table1 T2 
    WHERE T2.Date >= @startDate 
        AND T2.Date <= @endDate 
        AND   T2.complete = 0)
    AND Table1.co IN (SELECT co FROM VIEW('ZERO')) 
SELECT @rcount = CAST(@@ROWCOUNT AS VARCHAR(10)) + ' ' + 'row(s) affected by UPDATE';
--*********************************************************
--* Print Results
--*********************************************************
DECLARE @eSubject varchar(250)
DECLARE @emailTo varchar(250)
SET @eSubject = 'Number of rows updated'   
SET @emailTo = 'me@me.com' 
EXEC msdb.dbo.sp_send_dbmail @recipients=@emailTo,
    @subject = @eSubject,
    @body = @rcount,
    @body_format = 'HTML';

更新が行われていない場合、ジョブは完全に実行されますが、更新がある場合は常に失敗します。このジョブが実行されるユーザーには、読み取りおよび書き込みアクセス権があります。表示されるエラーは、「文字列またはバイナリ データが切り捨てられます [sql220001] [エラー 8152]」です。なぜそれが失敗し続けるのか、私にはわかりません。

******************アップデート**********

私はここで夢中になります。スケジュールされたジョブとしては失敗しますが、他のユーザーの下でストレート クエリとして完全に実行されます。フィールドは次のとおりです。

Table1.field1 = 10 の PK 長 Table1.field2 = 1 のビット長 Table1.field3 = 1 のビット長

何をしようとしても、SQLジョブを実行しても同じエラーで失敗しますが、クエリを単独で実行でき、問題なく動作することに夢中になっています。

4

7 に答える 7

4

@rcount を に変更してみてくださいvarchar(50)。それが問題だと思います。

編集：

私の最初の提案では問題が解決しなかったため、テーブルでトリガーを探してください。たとえば、50 文字を varchar(25) フィールドに入力しようとするトリガーが実行されている場合にも、そのエラーが発生する可能性があります。

今後、set コマンド (または @var = [ここにデータを挿入] を選択) の前にLEFT([insert data here], #) (# はそのフィールドの最大長) を実行することで、このエラーを回避できます。

于 2014-04-16T20:31:14.607 に答える
4

問題の原因となっている Table1 にいくつかのトリガーが設定されている可能性がありますか? ある場合は、それらのコードも確認する必要があります。

于 2014-04-14T09:13:00.887 に答える
3

変数@rcountの最大サイズは に設定されてい10ます。例えばVARCHAR(10)。

ただし、show SQL の最後に次のように表示されます。

SELECT @rcount = CAST(@@ROWCOUNT AS VARCHAR(10)) + ' ' + 'row(s) affected by UPDATE';

これは、少なくとも最大サイズの 2 倍です。@rcountを大きくしてみてくださいVARCHAR。

-RosSQL

于 2014-04-23T14:11:49.743 に答える
2

クエリを分析します。実行するたびに 1 つのステートメントを追加して、どのビットに問題があるかを正確に把握できるようにします。ジョブが使用する資格情報を使用して実行してください。

初め

USE DB
DECLARE @startDate AS DATETIME
DECLARE @endDate AS DATETIME
DECLARE @rcount AS VARCHAR(10)
SET @startDate = CAST(CONVERT(VARCHAR(10),GETDATE(),112) AS DATETIME) 
SET @endDate = CAST(CONVERT(VARCHAR(10),GETDATE(),112) AS DATETIME)

それで

USE DB
DECLARE @startDate AS DATETIME
DECLARE @endDate AS DATETIME
DECLARE @rcount AS VARCHAR(10)
SET @startDate = CAST(CONVERT(VARCHAR(10),GETDATE(),112) AS DATETIME) 
SET @endDate = CAST(CONVERT(VARCHAR(10),GETDATE(),112) AS DATETIME) 
--*********************************************************
-- *Run Query
--*********************************************************
UPDATE Table1
SET Table1.field1 = 'ZPR' +  Left(Table1.field1,6),
    Table1.field2 = '0',
    Table1.field3 = '0' 
WHERE  Table1.GUID IN (SELECT GUID FROM Table1 T2 
    WHERE T2.Date >= @startDate 
        AND T2.Date <= @endDate 
        AND   T2.complete = 0)
    AND Table1.co IN (SELECT co FROM VIEW('ZERO'))

どの部分が例外をスローするかが正確にわかるまで。

発言になると思いUPDATE Table1ます。それを分析し始めます。field1 のみを更新してから、field1 と field2 などを更新して一度実行します。

私の推測では、あなたとジョブを実行する資格情報の既定のスキーマが異なります。オプティマイザーは、ユーザーとジョブに対して異なるオブジェクトのセットを使用しています。私の推測では、あなたの Table1.field1 はジョブの Table1.field1 とは異なる長さです。修正は、オブジェクト参照の前にスキーマ ie を付けることUPDATE dbo.Table1です。すべてのステートメントでこれを行うのがベスト プラクティスです。

余談ですが、field2 と field3 は bit として定義されていますが、char(1) に設定しています。引用符を削除し、暗黙的な型変換を保存します。 WHERE T2.Date >= @startDate AND T2.Date <= @endDateとして見栄えがしますWHERE T2.Date BETWEEN @startDate AND @endDate。

于 2014-04-17T06:50:00.430 に答える
2

ジョブでこのステートメントをコメントアウトして、これが機能するかどうかを確認してください。編集で説明したことから、定義と割り当ては問題ないようです。

  SELECT @rcount = CAST(@@ROWCOUNT AS VARCHAR(10)) + ' ' + 'row(s) affected by UPDATE';
于 2014-04-23T19:16:33.843 に答える