Getting the data for last month of every year

Question

Hi,
       How to declare the date if we want to pull the data from the December of every year.
For example if the query is run in march 2015 and they want the historical data it should pull only the data from dec 2014.
In the same way if they ran the query in future jun 2016 and if they want to historical data it should pull only data from dec 2015.
It should not coded manually. Please help me with date format that need to used.
BALUSUSRIHARSHA

Answer 1

Please follow basic Netiquette and post the DDL we need to answer this. Follow industry and ANSI/ISO standards in your data. You should follow ISO-11179 rules for naming data elements. You should follow ISO-8601 rules for displaying temporal data. We need
to know the data types, keys and constraints on the table. Avoid dialect in favor of ANSI/ISO Standard SQL. And you need to read and download the PDF for: 
https://www.simple-talk.com/books/sql-books/119-sql-code-smells/
A table has to have a key to be table.  Here is my guess at a repair job: 
CREATE TABLE Test_Data
(pu_id INTEGER NOT NULL
  REFERENCES PU(pu_id),
 pu_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
 PRIMARY KEY (pu_id, pu_date),
 x_count INTEGER,
 y_count INTEGER);
Identifiers are not numeric in a good schema. What math do you do with them? They are also the key in the table that models the entity they identify. Where is the PU table (and what is a PU anyway)? 
INSERT INTO Test_Data
VALUES
(28, '2014-01-01', 10, 20), -- crap! No key in this mess!! 
(28, '2015-01-01', 30, 20), -- 
(28, '2014-12-12', 10, 20), 
(28, '2015-02-02', 10, 20);
A PIVOT is not a query and not even part of SQL. It is how Microsoft programmers who do not know RDBMS or have a report writer violate the tiered architecture of SQL. We also do not use XML mixed in SQL. It is a bitch to maintain, has poor performance and again
violates the tiered architecture principle. 
A query is not sorted because it is a table. A file in COBOL can be sorted and that seems to be what you really want to write. 
Old COBOL love the Sybase CONVERT() string function to avoid SQL temporal data. 
We never use SELECT * in production code; Google it. Not only are you generating code, you are generation bad code. 
Since SQL is a database language, we prefer to do look ups and not calculations. They can be optimized while temporal math messes up optimization. A useful idiom is a report period calendar that everyone uses so there is no way to get disagreements in the DML.
The report period table gives a name to a range of dates that is common to the entire enterprise. 
CREATE TABLE Month_Periods
(month_name CHAR(10) NOT NULL PRIMARY KEY
   CHECK (month_name LIKE <pattern>),
 month_start_date DATE NOT NULL,
 month_end_date DATE NOT NULL,
  CONSTRAINT date_ordering
    CHECK (month_start_date <= month_end_date),
etc);
These report periods can overlap or have gaps. I like the MySQL convention of using double zeroes for months and years, That is 'yyyy-mm-00' for a month within a year and 'yyyy-00-00' for the whole year. The advantages are that it will sort with the ISO-8601
data format required by Standard SQL and it is language independent. The pattern for validation is '[12][0-9][0-9][0-9]-00-00' and '[12][0-9][0-9][0-9]-[01][0-9]-00'
This will port and waste time calling string function row by row. 
--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