SQL 2000 Geplante Jobs Max. Zeichen

Question

Ich versuche, ein langes T-SQL-Skript zu planen. Das Skript wird jedoch abgeschnitten, wenn es in das Textfeld eingefügt wird. Ich habe das Problem gegooglet und es gibt eine Grenze von 3200 Zeichen.

Was empfehlen Sie, um dies zu lösen? Erstellen Sie eine gespeicherte Prozedur, und führen Sie das als einen geplanten Job aus? Gibt es eine bessere Option? Wenn es hilft, hier ist das Skript.

INSERT INTO CheltonCustomizations..SOBacklogAudits (SoNo, 
                 SoRev, 
                 SysItemNo, 
                 UserItemNo, 
                 Release, 
                 OrderDate, 
                 DueDate, 
                 PartNo, 
                 PartRev, 
                 OrderQty, 
                 ShippedQty, 
                 ShippedNotInvoicedQty, 
                 InvoicedQty, 
                 ProdCl, 
                 [Group], 
                 NetAmount, 
                 SorelsIdentityColumn, 
                 BacklogDate) 
       SELECT SOR.fsono, 
         SOM.fsorev, 
         SOR.fenumber, 
         SOR.finumber, 
         SOR.frelease, 
         SOM.[forderdate], 
         SOR.fduedate, 
         SOR.fpartno, 
         SOR.fpartrev, 
         SOR.forderqty, 
         SOR.fshipbook + SOR.fshipbuy + SOR.fshipmake, 
         COALESCE (
          DBO.GETSHIPPEDNOTINVOICEDQTY (
           SOR.fsono + SOR.finumber + SOR.frelease), 
          0), 
         SOR.finvqty, 
         SOI.fprodcl, 
         SOI.fgroup, 
         (SOR.forderqty - SOR.finvqty 
         - COALESCE (
           DBO.GETSHIPPEDNOTINVOICEDQTY (
           SOR.fsono + SOR.finumber + SOR.frelease), 
           0)) 
         * SOR.funetprice, 
         SOR.identity_column, 
         getdate() 
         --CONVERT (DATETIME, '02/09/2009') 
        FROM SORELS SOR 
         INNER JOIN SOITEM SOI 
         ON SOR.finvqty < 
           SOR.forderqty 
           - COALESCE (
            DBO.GETSHIPPEDNOTINVOICEDQTY (
             SOI.FSONO + SOR.finumber + SOR.frelease), 
            0) 
           - 0 
          AND SOR.finvqty < 
           SOR.forderqty 
           - COALESCE (
             DBO.GETSHIPPEDNOTINVOICEDQTY (
             SOR.fsono + SOI.FINUMBER + SOR.frelease), 
             0) 
           - 0 
          AND SOR.FSONO = COALESCE (SOI.FSONO, SOI.FSONO) 
          AND SOR.FINUMBER = SOI.FINUMBER 
         INNER JOIN SOMAST SOM 
         ON SOR.finvqty < 
           SOR.forderqty 
           - COALESCE (
            DBO.GETSHIPPEDNOTINVOICEDQTY (
             SOM.FSONO + SOR.finumber + SOR.frelease), 
            0) 
           - 0 
          AND SOR.FSONO = COALESCE (SOM.FSONO, SOM.FSONO) 
          AND SOI.FSONO = SOM.FSONO 
        WHERE SOM.FSTATUS = 'OPEN' AND FMASTERREL = COALESCE (0, 0) 
         AND SOM.forderdate >= 
           CONVERT (DATETIME, '01/01/2002') 
         AND SOR.forderqty > 
           0 + SOR.finvqty 
           + COALESCE (
            DBO.GETSHIPPEDNOTINVOICEDQTY(SOR.fsono 
                   + SOR.finumber 
                   + SOR.frelease), 
            0) 
         AND SOR.finvqty < 
           SOR.forderqty 
           - COALESCE (
            DBO.GETSHIPPEDNOTINVOICEDQTY(SOR.fsono 
                   + SOR.finumber 
                   + SOR.frelease), 
            0) 

Answer 1

Wie Sie erwähnt haben, würde ich eine gespeicherte Prozedur verwenden, rufen Sie das aus dem Job.

Sie haben auch den Vorteil, dass Sie den Code aktualisieren, aber die Arbeit unberührt

Answer 2

machen es zu einem gespeicherten Prozedur verlassen. Ich würde nie etwas anderes als eine gespeicherte Prozedur ausführen lassen. Sie können weiterhin Logik usw. zum Vorgang hinzufügen und den Job überhaupt nicht durcheinander bringen ...

Answer 3

Stimmen Sie mit oben überein - setzen Sie es definitiv in einen gespeicherten proc und nennen Sie es vom Job.

Es ist generell eine gute Übung, den gesamten Code in gespeicherte Prozeduren zu schreiben. Auf diese Weise können Sie eine gespeicherte Prozedur zu einem späteren Zeitpunkt problemlos namentlich aufrufen (z. B. für die Verwendung in einem Job oder DTS-Paket).

Wenn Sie jemals mehrere Jobs oder DTS-Pakete erstellen mussten, die dieselbe gespeicherte Prozedur aufrufen und Änderungen an dieser gespeicherten Prozedur vornehmen mussten, mussten Sie die Änderung nur einmal vornehmen.

Wenn Sie den Code einfach in das Job-/DTS-Paket kopiert haben, müssen Sie jeden einzelnen Schritt ausführen, um Ihren Code zu aktualisieren, wenn Änderungen erforderlich sind.