Difference between SUM values in adjoining rows

Question

Hi I've written following query:
DECLARE @Decision_Group nvarchar(10) = 'All',
@Entry_Month INT = 09,
@In_Use CHAR(1) = 'Y',
@Scheme nvarchar(05) = 'UGS',
@Subject_Area nvarchar(10) = 'ART',
@Location nvarchar(10) = 'UOB',
@Home_Overseas nvarchar(05) = 'H'
SELECT SUM(a.CONVERSION_EARLY) AS Early, SUM(a.CONVERSION_MIDDLE) AS Middle, SUM(a.CONVERSION_CLEARING) AS Clearing, a.AcademicYear
FROM
SELECT
srs_cap.cap_ayrc AS AcademicYear
,CONVERSION_EARLY =
CASE
WHEN (srs_cap.cap_crtd < cast('02/10/' + left(srs_cap.cap_ayrc,4) AS dateTime)) THEN 1
END
,CONVERSION_MIDDLE =
CASE
WHEN (
srs_cap.cap_crtd < cast('08/01/' + left(srs_cap.cap_ayrc,4) AS dateTime) AND
srs_cap.cap_crtd >= cast('02/10/' + left(srs_cap.cap_ayrc,4) AS dateTime)) THEN 1
END
,CONVERSION_CLEARING =
CASE WHEN (srs_cap.cap_crtd >= cast('08/01/' + left(srs_cap.cap_ayrc,4) AS dateTime)) THEN 1
END
FROM srs_cap
LEFT JOIN srs_mcr ON srs_cap.cap_mcrc = srs_mcr.mcr_code
LEFT JOIN srs_dsc ON srs_cap.cap_dscc = srs_dsc.dsc_code
LEFT JOIN srs_mth ON srs_cap.cap_mthc = srs_mth.mth_code
LEFT JOIN ins_lca ON srs_cap.cap_cgpc = ins_lca.lca_code
LEFT JOIN men_xon ON men_xon.xon_oldv = srs_cap.cap_dptc
LEFT JOIN ins_dpt ON srs_cap.cap_dptc=ins_dpt.dpt_code
LEFT JOIN srs_sce ON srs_cap.cap_scjc = srs_sce.sce_scjc
AND srs_cap.cap_ayrc = srs_sce.sce_ayrc
WHERE cap_ayrc BETWEEN dbo.[GetAcademicYear-2] (getdate()) AND dbo.getnextacademicyear(getdate())
AND (@Decision_Group='All' OR (@Decision_Group<>'A' AND RIGHT(srs_cap.cap_dscc,1) IN (left(@Decision_Group,1)) ))
AND cap_mthc IN (@Entry_Month)
AND srs_mcr.mcr_iuse IN (@In_Use)
AND srs_cap.cap_schc IN (@Scheme)
AND srs_cap.cap_dptc IN (@Subject_Area)
AND srs_cap.cap_cgpc IN (@Location)
AND srs_cap.cap_apcc IN (@Home_Overseas)
AND (men_xon.xon_tabl='Academic Group' or men_xon.xon_tabl IS NULL)
GROUP BY
srs_cap.cap_ayrc,
srs_cap.cap_crtd
AS a
GROUP BY
AcademicYear
This returns following data.
    Early
    Middle
  Clearing
AcademicYear
79
58
  27    
   2012/13
69
58
37
   2013/14
75
55
30
   2014/15
67
6
      NULL
   2015/16
Is there a simple way using windows functions to get the difference between Early 2012/13 and Early 2013/14, then Middle 2012/13 and Middle 2013/14 etc?
Cheers, AndySugs

Answer 1

Please follow basic Netiquette and post the DDL we need to answer t His. Follow industry and ANSI/ISO standards in your data. You should follow ISO-11179 rules for naming data elements. You are not even close. 
You should follow ISO-8601 rules for displaying temporal data. We need to know the data types, keys and constraints on the table. You failed again and did it in the worst way! Is your '08/01/'  supposed to be “yyyy-08-01” or “yyyy-01-08” ? Who knows? This
is why ANSI/ISO Standard SQL allows only the “yyyy-mm-dd” display format. 
Avoid dialect in favor of ANSI/ISO Standard SQL. 
Why did you treat temporal data like 1960's COBOL strings? And then you picked the worst possible display format! 
Why do you write with assembly language flags? 
Why did you write more left outer joins in ONE query than I have written in the last three years? Your DDL (which you did not post) would have to be total mess. 
Why do you think that table names of less than 8 characters are maintainable? I am old and remember when file names had to be less than 8 characters but that was in the 1970's on magnetic tape file systems. 
Why do you think that “cap_ayrc” is better than the ISO-1179 compliant “academic_year” that you had to alias it to? In RDBMS, a data element has one and only one name. This name does not contain meta data. The general syntax is “<attribute>_<attribute
property>”
The old Sybase/UNIX  getdate() should be CURRENT_TIMESTAMP today. 
Competent SQL programmers do not use UDF. They do not port, the overhead is too great and they cannot be optimized. But VB, COBOL and programmers in other procedural languages use them to avoid learning declarative programming. This means your silly [Get_Academicyear-2]
() and Get_Next_Academicyear() would be in a report period look-up table. SQL is a data base language so we use tables instead of computations. 
Why did you write code like:
 S.cap_schc IN (@scheme_name) ?
The IN() predicate implies that you are passing a list. But First Normal Form (1NF) uses scalars. That would be sooo wrong! 
My guess is that when you fix the schema, this query would look more like this skeleton: 
SELECT A.academic-year,
            SUM (CASE  WHEN (A.foobar_date < R.something_start_date)  
                     THEN 1 ELSE 0 END)) AS early_conversion_cnt, 
            SUM (CASE  WHEN (A.foobar_date BETWEEN R.something_start_date
                         AND R.something_end_date)  AS middle_conversion_date
                     THEN 1 ELSE 0 END)) AS early_conversion_cnt, 
            SUM (CASE  WHEN (A.foobar_date >  R.something_end_date)  
                     THEN 1 ELSE 0 END)) AS AS clearing_conversion_cnt
FROM  Report_Periods AS R,  .. AS A
WHERE  .. ;
Do you want to follow the forum rules and try again with DDL and specs? Having taught SQL and having other credentials, I would say that you are 3-5 years from being a productive SQL programmer. 
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL