none
comment savoir par quelle étape a été appelée une autre étape RRS feed

  • Question

  • j'ai un travail de l'agent SQL qui comporte 4 étapes qui sont paramétrées comme suit :

    Étape 1    action en cas de succès : passer à l'étape suivante                              action en cas d'échec : passer à l'étape 4
    Étape 2    action en cas de succès : passer à l'étape suivante                              action en cas d'échec : passer à l'étape 4
    Étape 3    action en cas de succès : quitter en signalant la réussite                      action en cas d'échec : passer à l'étape 4
    Étape 4    action en cas de succès : quitter en signalant l'échec                           action en cas d'échec : quitter en signalant l'échec

    Dans mon étape N° 4 je voudrais bien savoir qu'elle étape l'a appelée??? est-ce possible.

    Cela me servirait a exécuter une Procédure Stockée avec comme argument (entre autre), l'étape ou c'est dérouler le problème.

    Cordialement,

    AMDMAN_fr
    lundi 3 août 2009 20:20

Réponses

  • Depuis l'interface de gestion des jobs non. Il est juste possible de récupérer le numéro d'étape courant par les tokens.

    Cependant si vos étapes de jobs sont des scripts TSQL, rien ne vous empêche de créer une table de travail et de l'alimenter avec les différentes étapes.

    Ex :

    1-
    CREATE TABLE dbo.etape
    (
     ID INT NOT NULL
    )

    2-
    Exécution de votre job

    Etape 1 --> INSERT INTO dbo.t_etape VALUES (1) --> reussite
    Etape 2 --> INSERT INTO dbo.t_etape VALUES (2) --> echec
    Etape 4 --> SELECT MAX(no_etape) FROM dbo.t_etape + EXECUTE PROCEDURE + Suppression enregistrement table dbo.etape


    Une autre solution serait de passer par SSIS ou DTS qui permet de gérer plus facilement ce genre de cas.

    ++





    MCDBA | MCITP SQL Server 2005 | LPI 1
    • Marqué comme réponse AMDMAN_fr dimanche 30 août 2009 12:47
    lundi 3 août 2009 21:56
    Modérateur

Toutes les réponses

  • Depuis l'interface de gestion des jobs non. Il est juste possible de récupérer le numéro d'étape courant par les tokens.

    Cependant si vos étapes de jobs sont des scripts TSQL, rien ne vous empêche de créer une table de travail et de l'alimenter avec les différentes étapes.

    Ex :

    1-
    CREATE TABLE dbo.etape
    (
     ID INT NOT NULL
    )

    2-
    Exécution de votre job

    Etape 1 --> INSERT INTO dbo.t_etape VALUES (1) --> reussite
    Etape 2 --> INSERT INTO dbo.t_etape VALUES (2) --> echec
    Etape 4 --> SELECT MAX(no_etape) FROM dbo.t_etape + EXECUTE PROCEDURE + Suppression enregistrement table dbo.etape


    Une autre solution serait de passer par SSIS ou DTS qui permet de gérer plus facilement ce genre de cas.

    ++





    MCDBA | MCITP SQL Server 2005 | LPI 1
    • Marqué comme réponse AMDMAN_fr dimanche 30 août 2009 12:47
    lundi 3 août 2009 21:56
    Modérateur
  • Décidément, vous êtes sur tout les fronts !!!

    J'y avais pensé, mais je cherchais une solution utilisant une des nombreuses capacités de TSQL.

    Par contre je ne savais pas que SSIS pouvait s'occuper de cas comme cela, pourriez-vous m'en dire un peut plus???

    Cordialement,

    AMDMAN_fr
    mardi 4 août 2009 08:28
  • J'essaie d'aider au mieux :-)

    SSIS vous permet de faire énormément de choses à la base. De l'intégration de données à la résolution de problèmes complexes tel que le votre où chaque action dépend d'une autre. SSIS vous permet de créer et gérer vos propres "workflow" qui peuvent être complexes.

    Avec SSIS vous pouriez tout à fait gérer votre problème de façon simple et graphique.
    Pour chaque étape une tâche de script. Entre ces tâches une simple contrainte de réussite ou d'échec . Pour mémoriser vos étapes, une variable dont l'étendue est votre package. Vous pourriez ainsi lancer la procédure que vous voulez avec votre numéro d'étape....

    ++
    MCDBA | MCITP SQL Server 2005 | LPI 1
    mardi 4 août 2009 11:10
    Modérateur
  • Pour faire avancé un peu le chmilblik comme aurait dit notre regretté Coluche, voici un article intéressent, bien qu'en Anglais : 

    http://www.sqlservercentral.com/articles/SQL+Server+Agent/67726/

    En espérant que cela puisse en aider d'autre

    @+

    AMDMAN_fr
    mercredi 9 septembre 2009 14:02