none
Wie heißt das Verhalten, wie sich Aufrufe von SET <OPTION> in aufgerufenen Prozeduren nach außen auswirken RRS feed

  • Frage

  • Hallo,

    folgendes Beispiel:

    -- called proc
    create or alter proc foobar
    as
    -- modify nocount option
    IF @@OPTIONS & 512 > 0 RAISERROR ('foobar #1: NOCOUNT turned on.', 1, 1) ELSE RAISERROR ('foobar #1: NOCOUNT turned off.', 1, 1);
    
      SET NOCOUNT ON;
    
    IF @@OPTIONS & 512 > 0 RAISERROR ('foobar #2: NOCOUNT turned on.', 1, 1) ELSE RAISERROR ('foobar #2: NOCOUNT turned off.', 1, 1);
    GO
    
    
    -----------------------------------
    -- main script
    IF @@OPTIONS & 512 > 0 RAISERROR ('main #1: NOCOUNT turned on.', 1, 1) ELSE RAISERROR ('main #1: NOCOUNT turned off.', 1, 1);
    exec foobar;
    IF @@OPTIONS & 512 > 0 RAISERROR ('main #2: NOCOUNT turned on.', 1, 1) ELSE RAISERROR ('main #2: NOCOUNT turned off.', 1, 1);
    GO

    In der aufgerufenen SP wird die Option NOCOUNT umgesetzt. Im aufrufenden Skript ist die Option nach Abschluss der SP jedoch nicht gesetzt. Dieses Verhalten ist total plausibel und gut so, allerdings finde ich keinerlei Dokumentation darüber. Kann mir jemand auf die Sprünge helfen?

    Ich bereite aktuell eine SQL Schulung für Azubis vor und möchte das etwas besser erklären können.

    main #1: NOCOUNT turned off.
    Msg 50000, Level 1, State 1
    foobar #1: NOCOUNT turned off.
    Msg 50000, Level 1, State 1
    foobar #2: NOCOUNT turned on.
    Msg 50000, Level 1, State 1
    main #2: NOCOUNT turned off.
    Msg 50000, Level 1, State 1

    Vielen Dank!





    • Bearbeitet Do Django Montag, 6. Mai 2019 09:39
    Montag, 6. Mai 2019 09:32

Alle Antworten

  • Nun ja, da hilft ein wenig interpretieren:

    SET NOCOUNT ON verhindert das Senden der DONE_IN_PROC-Meldungen an den Client, die sonst für jede Anweisung in einer gespeicherten Prozedur gesendet werden.

    Bei anderen Optionen staht da dann schon mal, dass diese für die gesamte Sitzung gilt. Allgemein gibts da keine Regel.

    Montag, 6. Mai 2019 11:01
  • Danke. Dasselbe Verhalten gilt aber auch für zum Beispiel ANSI_WARNINGS, wobei es hier keine Gültigkweitsinfo in der Doku gibt :-(

        -- called proc
        create or alter proc foobar
        as
        -- modify ANSI_WARNINGS option
        IF @@OPTIONS & 8 > 0 RAISERROR ('foobar #1: ANSI_WARNINGS turned on.', 1, 1) ELSE RAISERROR ('foobar #1: ANSI_WARNINGS turned off.', 1, 1);
        
          SET ANSI_WARNINGS OFF;
        
        IF @@OPTIONS & 8 > 0 RAISERROR ('foobar #2: ANSI_WARNINGS turned on.', 1, 1) ELSE RAISERROR ('foobar #2: ANSI_WARNINGS turned off.', 1, 1);
        GO
        
        
        -----------------------------------
        -- main script
        IF @@OPTIONS & 8 > 0 RAISERROR ('main #1: ANSI_WARNINGS turned on.', 1, 1) ELSE RAISERROR ('main #1: ANSI_WARNINGS turned off.', 1, 1);
        exec foobar;
        IF @@OPTIONS & 8 > 0 RAISERROR ('main #2: ANSI_WARNINGS turned on.', 1, 1) ELSE RAISERROR ('main #2: ANSI_WARNINGS turned off.', 1, 1);
        GO

    Montag, 6. Mai 2019 14:10