• That's what I'm talking about... You have the Users and the Subscription service (whatever that is for you) calling the same proc and you're running into trouble.

    The "final" proc should accept date parameters without any defaults no matter what. When a User calls the proc, they call it directly with the required date parameters.

    The Subscription service should NOT call the same proc directly. Instead, the Subscription service should call a similarly named proc (I use procname_SS where SS stands for "Subscription Service"). That proc contains the necessary datemath to make two correct date parameters for the preceeding month and then it calls the "final" proc with the correct date parameters. It makes life REAL easy.

    So far as the calculation problem you're having with January, why aren't you using the DATEADD function to do your work for you? It KNOWS how to handle dates correctly so you don't need to worry about it. 🙂

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)