Calendar Tables are only useful if they reflect how your company evaluates its data. Therefore, any company using non-standard financial fiscal years and periods will require customization with their Calendar or Date Table. In this post, I’ll provide an example of how to do so using the M2M ERP System Database. For those who don’t use M2M, the notes should serve as an example of how to do so with other systems.

The most effective way to determine the fiscal setup of a company is to determine how its major systems track the data. In M2M the source is the GL Rules and Periods (GLRule) table. There are four primary fields of interest, which I’ve aliased, and they are listed in the following query and screenshot.

SELECT GLR.fcname AcctYearName
      ,GLR.fnnumber PeriodNo
      ,GLR.fdstart FirstDayOfPeriod
      ,GLR.fdend LastDayOfPeriod
  FROM dbo.glrule GLR

As you can see, there is one record for each fiscal period in GLRule. FCName is a Char(20) field and typically contains values like “FY 2005″ or “Fiscal Year 2005″. FNNumber contains the period number and is an Int datatype. FDStart and FDEnd are Datetime fields and represent the first and last days of each period.

What follows are the update statements which I use to customize the fiscal periods of my calendar table. For your convenience, you can access the entire script here****. Copy and paste the entire query, replace the database and table name, and run it. I’ve dissected each step of the script below so those not using M2M can understand my logic and mimic those steps with their own systems.

Six fields are updated by the first statement. Notice that I’ve joined the Calendar Table to GLRule with a between statement. I’m using the pattern matching of Patindex to find the four digit number for Fiscal Year. However, if the user entered something like “Two Thousand Five” as a Fiscal Year, this method will not work. Start and end of period fields are taken directly out of GLRule as well. FiscalDayOfPeriod is calculated in this step as well for good measure.

Use M2MDataXX
GO
UPDATE TST
   SET TST.[FiscalYearName] =
        substring (GLR.fcName, patindex ('%[1,2][9,0,1,2][0-9][0-9]%', GLR.fcName), 4)
      ,TST.[FiscalYearPeriod] =
        (substring (GLR.fcName, patindex ('%[1,2][9,0,1,2][0-9][0-9]%', GLR.fcName), 4))
        + + (GLR.fnnumber / 100.00)
      ,TST.[FiscalPeriod] = GLR.fnnumber
      ,TST.[FiscalStartOfPeriodDate] = GLR.fdstart
      ,TST.[FiscalEndOfPeriodDate] = GLR.fdend
      ,TST.[FiscalDayOfPeriod] = (DATEDIFF (dd, GLR.fdstart, TST.[DATE]) + 1)
  FROM  DateTestStnd.dbo.DimDate TST
       INNER JOIN
        glrule GLR
       ON TST.DATE BETWEEN GLR.fdstart AND GLR.fdend

In this step, I’ve calculated the beginning and end of Fiscal Years. I group the record set in GLRule by Fiscal Year and then use min/max to determine the first and last day in each group.

UPDATE TST
   SET TST.[FiscalStartOfYearDate] = M2MYEARS.[FiscalStartOfYearDate]
      ,TST.[FiscalEndOfYearDate] = M2MYEARS.[FiscalEndOfYearDate]
  FROM  DateDatabase.dbo.DimDate TST
       INNER JOIN
        (SELECT substring (GLR.fcName, patindex ('%[1,2][9,0,1,2][0-9][0-9]%', GLR.fcName), 4)
                 FiscalYearName
               ,min (GLR.fdstart) [FiscalStartOfYearDate]
               ,max (GLR.fdend) [FiscalEndOfYearDate]
           FROM glrule GLR
         GROUP BY GLR.fcname) M2MYEARS
       ON TST.FiscalYearName = M2MYEARS.FiscalYearName

In the next step, I calculate the FiscalDayofYear and FiscalYearDayOfYear field. While I could have included this code in the previous step, it’s much easier to read and understand as a separate step. The FiscalDayOfYear calculation is simple and is simply the number of days between the current record and the first day Fiscal Year calculated previously. The FiscalYearDayOfYear is the same calculation, but I convert the integer (day) to a decimal and add it to the Fiscal Year integer. This makes drill down and grouping easier.

UPDATE TST
   SET TST.[FiscalDayOfYear] = (DATEDIFF (dd, [FiscalStartOfYearDate], TST.[DATE]) + 1)
      ,TST.[FiscalYearDayOfYear] =
        (datepart (year, TST.[DATE])
         + cast (
            (datediff (dd, dateadd (yy, datediff (yy, 0, TST.[DATE]), 0), TST.[DATE]) + 1)
            / 1000.00 AS NUMERIC (3, 3)))
   FROM  DateDatabase.dbo.DimDate TST

The next section looks complex because I have to determine whether the number of Fiscal Periods can be broken into Quarters and Semesters. If a company used 10 Fiscal Periods per year, the concept of Quarters doesn’t make sense, but Semesters do. To make the code easier to understand, I’ve numbered the sections.

Section 1 checks whether the number of periods per fiscal year can be divided into quarters and semesters and the number of periods in each. Section 2 includes the period start and end dates so that the values of quarter and semester can be related back to the date table. Values for quarter or semester will be set to 0 if they aren’t valid in a particular M2M install.

UPDATE TST
   SET [FiscalQuarter] =
        CASE M2MYEARS.Quarterific
         WHEN 'Yes' THEN (ceiling (CAST (M2MYEARS.PeriodNo AS DECIMAL (4, 2)) / M2MYEARS.QuarterSize))
         ELSE 0
        END
      ,[FiscalSemester] =
        CASE M2MYEARS.Semesterific
         WHEN 'Yes' THEN (ceiling (CAST (M2MYEARS.PeriodNo AS DECIMAL (4, 2)) / M2MYEARS.SemesterSize))
         ELSE 0
        END 
  FROM  DateTestStnd.dbo.DimDate TST
       INNER JOIN
 -------------- 2. Include Start and End of Period Values. 
        (SELECT fcname FYName
               ,fdstart PeriodStart
               ,fdend PeriodEnd
               ,fnnumber PeriodNo
               ,GLRAGG.QuarterSize
               ,GLRAGG.Quarterific
               ,GLRAGG.SemesterSize
               ,GLRAGG.Semesterific
           FROM  dbo.glrule GLR
                INNER JOIN
  -------------- 1. Calculate whether Quarters and Semesters are Valid (and their values)
                 (SELECT fcname AGGFYName
                        ,MAX (fnnumber) PeriodCount
                        , (Max (fnnumber) / 4) QuarterSize
                        ,CASE WHEN Max (fnnumber) % 4 = 0 THEN 'Yes' ELSE 'No' END AS Quarterific
                        , (Max (fnnumber) / 2) SemesterSize
                        ,CASE WHEN Max (fnnumber) % 2 = 0 THEN 'Yes' ELSE 'No' END AS Semesterific
                    FROM dbo.glrule
                  GROUP BY fcname) GLRAGG
                ON GLR.FCNAME = GLRAGG.AGGFYNAME) M2MYEARS
 -------------- End of 1
       ON TST.DATE >= M2MYEARS.PeriodStart AND TST.DATE <= M2MYEARS.PeriodEnd
  -------------- End of 2

Workday calculation is also somewhat difficult to understand. In M2M this information is kept in the Production Calendar (SCCALN) table. The fields we care about are:

• fcYrMon – Year and month in the format of YYYY/MM (2011/02). Unfortunately these are not per Fiscal Year or Period, they are by Calendar Year and Month.
• fcShifts – A Varchar (31) field with the number of Shifts per day.

Needless to say, we need an easier way than parsing through this table every time we need to calculate work days. The join is a little strange because the Date Table CalendarYear and CalendarMonth fields are SmallInt and need to be cast as Varchar. I’ve used a left join because many M2M companies don’t use the Production Calendar so SCCALN may lack records for fiscal periods.

Basically the code checks for a corresponding record in SCCALN. If one does not exist, then the typical Monday through Friday work week is used by default. If it does exist the fcShifts field is parsed, and if there are one or more shifts for a particular day, then the date is designated a work day.

UPDATE TST
   SET WorkDay =
        CASE
         WHEN wc.fcShifts IS NULL THEN
           CASE WHEN TST.CalendarDayOfWeek IN (1, 7) THEN 'No Work' ELSE 'Work Day' END
         ELSE
           CASE
            WHEN substring (WC.fcShifts, TST.CalendarDayOfMonth, 1) = '0' THEN 'No Work'
            ELSE 'Work Day'
           END
        END
      ,IsWorkDay =
        CASE
         WHEN WC.fcShifts IS NULL THEN 
           CASE WHEN TST.CalendarDayOfWeek IN (1, 7) THEN 0 ELSE 1 END
         ELSE 
           CASE WHEN substring (WC.fcShifts, TST.CalendarDayOfMonth, 1) = '0' THEN 0 ELSE 1 
           END
        END
  FROM  DateDatabase.dbo.DimDate TST
       LEFT JOIN
        dbo.ScCaln WC
       ON WC.fcYrMon = cast (TST.CalendarYear AS Varchar (4))
           + '/'
           + right ('0' + cast (TST.CalendarMonth AS Varchar (2)), 2)

The final bit of code updates the FiscalWeekName and FiscalYearWeekName. This code is tailored to my current employer, and I consider it optional because it may not pertain to you. The logic is as follows:

1. The first fiscal week starts on the first day of the fiscal period.
2. Fiscal weeks end on Friday and begin on Saturday.
3. A “partial week” where the week starts on a day other than Saturday is added to the next full week. Partial weeks ending a period are considered their own week.
4. Week names follow the pattern of [FiscalPeriod].[WeekNumber] both of which are integers. For example, the second week of the fifth period would be designated as “5.2″.

Again, this is a specific requirement and it may not apply to most companies.

UPDATE TST
   SET FiscalWeekName =
        TST.FiscalPeriod
        + CASE ( (SELECT count (*)
                    FROM DateDatabase.dbo.DimDate TMP
                   WHERE TMP.CalendarDayOfWeek = 7
                         AND TMP.Date BETWEEN TST.FiscalStartOfPeriodDate AND TST.Date)
                / 10.0)
           WHEN 0 THEN
            .1
           ELSE
            ( (SELECT count (*)
                 FROM DateDatabase.dbo.DimDate TMP
                WHERE TMP.CalendarDayOfWeek = 7
                      AND TMP.Date BETWEEN TST.FiscalStartOfPeriodDate AND TST.Date)
             / 10.0)
          END
  FROM DateDatabase.dbo.DimDate TST
-- Updates FiscalYearWeekName from FiscalWeekName
UPDATE TST
   SET TST.FiscalYearWeekName =
          cast (TST.FiscalYearName AS CHAR (4))
        + '.'
        + (CASE len (TST.FiscalWeekName) WHEN 3 THEN '0' ELSE '' END)
        + cast (TST.FiscalWeekName AS CHAR (4))
  FROM DateDatabase.dbo.DimDate TST

In most systems, new fiscal years and periods are added once a year. The update script will need to be run after that happens. With Made2Manage, and presumably other systems, triggers could be used to detect those changes and then run the update script. In my own situation, I’ve chosen to save this update script as a scheduled job which runs weekly. This may seem wasteful, but the update script completes very quickly.

Technically, I could have integrated this script with the one I posted previously which would have been faster and more efficient. However, I use two scripts for several reasons. First, this method is more flexible as I can create any Fiscal Update script I want without editing the main calendar script. Second, the Fiscal Update script will need to be run periodically to get updates and dropping/recreating the entire date table would be wasteful. Finally, most systems do not track Fiscal Years and Periods a decade or more into the future. Therefore, the first script is required to set default values for the Fiscal fields and only those that exist in the source system are updated. The user will not receive an error on a report because a future fiscal date value was not supplied.

Well, there you have it. The last two articles have described how I create date tables and customize the Fiscal fields from a source system, in this case Made2Manage.

Any questions or suggestions to make the process better?

What is a Date (Calendar) Table?

For the purposes of this article a Date Table is a dedicated table containing a single record for each day in a defined range. They include fields with descriptive attributes for each day such as Year, Month, Week, and whether a particular day is a work day or not. Date Tables (Dimensions) are an integral part of every Data Warehouse, but they can be used with a regular (OLTP) database as well.

Why do I need a Date Table?

There are several situations in which a date table is extremely helpful. Let’s consider just a few. Suppose you need to….

• Generate a running sales total per day and include days in which you have no sales such as weekends.
• Calculate the number of workdays between two dates.
• Calculate projected ship dates for products based upon lead times.
• Aggregate data by non-standard Fiscal Years or Periods. Perhaps your company uses the Fiscal Year of the US Government which runs from October 1st until September 30th. My current employer uses the 4-4-5 Calendar methodology, which is what originally led me to create this Date Table script.
• Need to track data by seasons, whatever that means to your company. For example, if you manufactured bicycles you’d certainly want to compare sales figures in the spring versus fall.
• Need to compare data using rolling months/periods. Suppose your company wants to know how March sales for this year compared to March for the past 5 years. Or you want to compare sales which occurred on Fridays to each other to look for trends.
• Need to create Gantt Charts.

While many of these issues can be handled by writing T-SQL code, they’re much easier with a dedicated date table. Also, the Date Table can be customized to track anything about a particular day you want.

What about Space Considerations?

One concern that people have when creating a Date Table is the “wasted” space since each day is its own record. The space used is negligible, especially when compared to the benefits of having a dedicated date table. For example, when I execute my script for the years 2000 through 20035 the space used is less than 250MB.

How do I create a Date Table?

Kimball Date Dimensions
In the The Microsoft Data Warehouse Toolkit: With SQL Server 2008 R2and the previous 2005 version, the Kimball Group recommends that you create a Date Dimension using Excel. In the latest book, they provide a Date Dimension Spreadsheet which is available for Download and utilizes VBA to generate the table. They recommend you create a SSIS package to load that data into SQL Server.

While this will work, and some non-technical people might prefer this method, I prefer to use SQL Script, because I may not always have access to SSIS.

Using a SQL Script
When I searched for a Date Table Script a few years ago, I couldn’t find something suitable for my needs. Most of them include only one set of fields (regular Calendar) and I to report via custom fiscal calendars.

I created this script from a function called F_TABLE_DATE by Michael Valentine Jones from SQLTeam and have since gotten his permission to distribute it. I’ve modified the script so that it generates a Kimball style date dimension and it’s very comprehensive, yet simple to use and customize.

1. Create a database called DateDatabase or whatever you’d like to call it. We’ll install F_TABLE_DATE in it and presumably the Date Table as well.
2. Open the following script and replace “DateDatabase” (Find and Replace) with whatever database name you chose in step 1.
3. Run the Script to create the function.

Your database should now contain the function used to create Date Tables. As a test, run the following script:

SELECT * FROM dbo.F_TABLE_DATE ('20000101', '20101231')
ORDER BY 1

You should receive 4019 Rows, 11 years worth of days plus a record for unknown dates. Notice the extensive list of fields built into the function. All of them are documented in the script.

Use a Select Into statement to create the Date Table like so. Replace dbo.DimDate with whatever you’d like to call your Date Table.

IF EXISTS
     (SELECT 1
        FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_NAME = 'DimDate')
  BEGIN
        DROP TABLE dbo.DimDate;
  END
 
Select
  DateId
 ,Date
 ,NextDayDate
 ,CalendarYear
 ,CalendarYearQuarter
 ,CalendarYearMonth
 ,CalendarYearDayOfYear
 ,CalendarQuarter
 ,CalendarMonth
 ,CalendarDayOfYear
 ,CalendarDayOfMonth
 ,CalendarDayOfWeek
 ,CalendarYearName
 ,CalendarYearQuarterName
 ,CalendarYearMonthName
 ,CalendarYearMonthNameLong
 ,CalendarQuarterName
 ,CalendarMonthName
 ,CalendarMonthNameLong
 ,WeekdayName
 ,WeekdayNameLong
 ,CalendarStartOfYearDate
 ,CalendarEndOfYearDate
 ,CalendarStartOfQuarterDate
 ,CalendarEndOfQuarterDate
 ,CalendarStartOfMonthDate
 ,CalendarEndOfMonthDate
 ,QuarterSeqNo
 ,MonthSeqNo
 ,FiscalYearName
 ,FiscalYearPeriod
 ,FiscalYearDayOfYear
 ,FiscalYearWeekName
 ,FiscalSemester
 ,FiscalQuarter
 ,FiscalPeriod
 ,FiscalDayOfYear
 ,FiscalDayOfPeriod
 ,FiscalWeekName
 ,FiscalStartOfYearDate
 ,FiscalEndOfYearDate
 ,FiscalStartOfPeriodDate
 ,FiscalEndOfPeriodDate
 ,ISODate
 ,ISOYearWeekNo
 ,ISOWeekNo
 ,ISODayOfWeek
 ,ISOYearWeekName
 ,ISOYearWeekDayOfWeekName
 ,DateFormatYYYYMMDD
 ,DateFormatYYYYMD
 ,DateFormatMMDDYEAR
 ,DateFormatMDYEAR
 ,DateFormatMMMDYYYY
 ,DateFormatMMMMMMMMMDYYYY
 ,DateFormatMMDDYY
 ,DateFormatMDYY
 ,WorkDay
 ,IsWorkDay
into
  dbo.DimDate -- Choose whatever name you like for your table.
From
  dbo.F_TABLE_DATE('20000101','20251231') -- Edit the parameters for a custom date range.
  Order By 1

Don’t panic, you don’t need to use all of the fields which is why this script is so highly customizable. Any fields you don’t want can be commented out before running the Select Into statement, which allows you to create your own custom Date Table.

The final step is to add a Primary Key to the DateID and an index for the Date and NextDayDate fields. As I can’t predict the usage patterns for your date table, you’ll have to implement further indexing if necessary.

ALTER TABLE [dbo].[DimDate]
ADD  PRIMARY KEY CLUSTERED ([DateId])
WITH FILLFACTOR = 100
 ON [PRIMARY]
GO
 
CREATE INDEX id_Dates
ON DateDatabase.dbo.DimDate 
	(Date, 
	 NextDayDate)

How do I use the Date Table?

Using the date table is simple, you simply link to it from the query from your source system. Use the following template.

SELECT
  MY.date
 ,DTE.CalendarYear
 ,DTE.CalendarMonthName
FROM
    MyTable MY
  INNER JOIN
    DateDatabase.dbo.DimDate DTE
  ON MY.date >= DTE.date AND
     MY.date < DTE.NextDayDate

Both DTE.Date and DTE.NextDayDate represent midnight of the two consecutive days. Therefore the time portion of a Datetime field can be ignored.

What about the fiscal fields?

After running these scripts, and examining the Date Table, you’ll notice that the fiscal fields mostly mirror the calendar fields. This is by design. In the next article I’ll explain how to customize the fiscal fields and a script to extract the fiscal information out of Made2Manage. Even if you don’t use M2M, you can still use the fiscal script as an example of how to do it.

Any questions?

In the previous post I mentioned the use of views to simplify querying your database in general and PowerPivot in particular.

What are Database Views?

Views are virtual tables, which you can create with a SQL statement. Some of the advantages of using views are:

1. Simplified Data Access – The view hides the data structure from the user making reporting less complex. Also, calculations can be performed in the view for them making their lives easier as well.
2. Security – Through the use of views you can easily limit your users to certain types of data in your database. You can restrict them from looking at specific tables, or even certain fields or rows in a database.
3. Standardization/Maintainability – The table logic for views is stored in the view itself. Therefore, if a change in that logic is required or the database structure changes, which happens occasionally when you upgrade M2M, the view need only be updated once. Otherwise every report, spreadsheet, etc. based on the changed areas must be edited.

View Security

As I’ve mentioned in the past, you should use a report login for your reporting with read only access. The simplest way to do so is to add a SQL Login and assign it the db_datareader role for that database. There are clear directions with screenshots covering this here. I create report logins which I creatively call ReportsXX, where XX represents which Made2Manage database that user will primarily report from. I use separate accounts per M2M company so different companies cannot see others data.

When creating these views, you should always create them with the same owner or in the same schema. In SQL 2000 objects were owned by a database user. When you look at the M2M database you’ll notice that every object is owned by dbo (database owner). Objects created in SQL 2000 tend to default to the owner who created them and if an account is designated as a database owner the default is dbo. In my case, all objects owned by Reports01 would be Reports01.ObjectName and would need to be referred to with their fully qualified name by any user other than Reports01.

The concept of database schemas was introduced in SQL 2005. Schemas serve as “containers” for objects and are useful for enforcing security as well as organization in the database. In this case you would create a schema called Reports01 (or Reports or whatever you like), and since your report login has the db_datareader role, it can also read from your views.

How do I Create a View?

As always, please read my standard disclaimer before implementing any code from my site. Creating a view is very simple. Let’s take the following SQL statement.

SELECT ARM.fcinvoice AS InvoiceNo,
       ARM.fcustno AS CustNo,
       ARM.fbcompany AS CompanyName,
       ARM.fdgldate AS PostDate,
       ARM.fsalespn AS SalesPerson,
       Rtrim (ARI.fpartno) AS PartNo,
       ARI.ftotprice AS NetInvoiced,
       ARI.fprodcl AS ProdClass,
       INM.fgroup AS GroupCode
  FROM dbo.armast ARM
       INNER JOIN dbo.aritem ARI
          ON ARM.fcinvoice = ARI.fcinvoice
       INNER JOIN dbo.inmast INM
          ON INM.fpartno = ARI.fpartno AND INM.frev = ARI.frev
 WHERE ARM.fcstatus <> 'V'

Please keep in mind that this is a simplified invoicing script for demonstration purposes. The templates I use are much more comprehensive and bring in many other related tables such as FastForms extension tables, the Sales Person table which contains their full name, portions of the Item Master table for product details, etc.

Further, it’s important to note that if you run that script on your database it will retrieve every applicable record since you started using M2M. With my current company that’s more than a decade of records. With input from the business leaders, we agreed to limit these views to the prior two fiscal years. While you could hard code these dates in with a statement like this, you shouldn’t do so.

 AND ARM.fdgldate >= '1/1/2008'

Instead, construct your view so that it automatically selects the previous two years.

 AND ARM.fdgldate >=  DATEADD(yy, DATEDIFF(yy,0,getdate())-2, 0)  -- In this case 1/1/2008

This lessens the performance impact on your server. So, how do you create a view from this? You adapt the code as follows:

USE M2MDataXX -- Replace XX with your M2M Company 
Go
 
CREATE VIEW ReportsXX.vw_Invoices
AS
   SELECT ARM.fcinvoice AS InvoiceNo,
          ARM.fcustno AS CustNo,
          ARM.fbcompany AS CompanyName,
          ARM.fdgldate AS PostDate,
          YEAR (ARM.fdgldate) AS PostYear,
          MONTH (ARM.fdgldate) AS PostMonth,
          CONVERT (VARCHAR (3), ARM.fdgldate, 100) AS OrderMonthName,
          ARM.fsalespn AS SalesPerson,
          Rtrim (ARI.fpartno) AS PartNo,
          ARI.ftotprice AS NetInvoiced,
          ARI.fprodcl AS ProdClass,
          INM.fgroup AS GroupCode
     FROM dbo.armast ARM
          INNER JOIN dbo.aritem ARI
             ON ARM.fcinvoice = ARI.fcinvoice
          INNER JOIN dbo.inmast INM
             ON INM.fpartno = ARI.fpartno AND INM.frev = ARI.frev
    WHERE ARM.fcstatus <> 'V'
 AND ARM.fdgldate >= DATEADD(yy, DATEDIFF(yy,0,getdate())-2, 0) 
Go

The view can be queried as if it were a SQL table, like so:

select CompanyName, InvoiceNo, NetInvoiced, PartNo FROM ReportsXX.vw_Invoices
where NetInvoiced > 1000 -- 1000 dollars

When run against the educational database the data returns like so:

You’ll notice that I’ve aliased the field names and replaced them with English. In programs such as SQL Reporting Services the alias names will be automatically formatted for you so NetInvoiced becomes Net Invoiced. Another advantage is that the view hides the table joins from the user as well and it looks like one object.

Now, keep in mind that what I’ve just shown you most likely violates your Consona User Agreement. You’re not really allowed to make changes to their database. The reason I say “most likely” is because I cannot get a definitive answer on this point from Consona.

Why do I need to bother with all that owner/schema stuff?

As I said before you can use them for security purposes and restrict user access only to the views you create. However, the most important reason is to make migration easier. When you migrate your M2M version, one of the first steps is a check of database objects and the installer may error out and quit if it finds objects that aren’t supposed to be there. Therefore, I document every view I create, run a script to drop all of the objects in the specific owner/schema, and migrate. After migration, I script all of my views back in, and begin testing them.

I wrote this simple script to drop all views belonging to a user in SQL 2000. Make sure to replace “ReportsXX” with the name of your report login and “M2MDataXX” with your database name.

--  SQL 2000
USE M2MDataXX
Go
 
DECLARE @UserName   VARCHAR (25)
DECLARE @ViewName   NVARCHAR (25)
DECLARE @SQL   VARCHAR (1000)
SET @UserName = 'ReportsXX'
-------------------------- 
SELECT [name] ViewName
  INTO #temp
  FROM sysobjects
 WHERE type = 'V' AND user_name (uid) = @UserName
--------------------------
DECLARE
   DropViews CURSOR FOR
      SELECT ViewName FROM #temp
 
 
OPEN DropViews
 
FETCH NEXT FROM DropViews INTO @ViewName
 
WHILE @@FETCH_STATUS = 0
BEGIN
   SET @SQL = N'Drop View ' + @UserName + '.' + @ViewName
   PRINT @sql
   --EXEC( @SQL)
   FETCH NEXT FROM DropViews INTO @ViewName
END
 
CLOSE DropViews
DEALLOCATE DropViews
 
DROP TABLE #temp

For SQL 2005 and after, simply replace the code between the horizontal lines with:

SELECT [name] ViewName
  INTO #temp
  FROM sys.objects
 WHERE type = 'V' AND schema_name (schema_id) = @UserName

Stay Tuned

In the near future, I will be posting more information about M-Data Analytics which has an entirely separate database, easily understood field names, and will have a multitude of views built in, etc. That doesn’t help you now, but I assure you, it is coming.

In the meantime you can simplify your life by using Database Views. In the next article in this series I’ll put it all together and show you the steps you’ll need to follow to successfully use technology like PowerPivot with problem databases.

Also, make sure to come back Monday when I share my entry in the Twelve Days of SQL Series. Not only will I share my choice for one of the best blog posts (and bloggers) this year, but I will reveal a picture of the tackiest Christmas Ornament you have ever seen. And before I show it, let me assure you that I really do own it, it really is on my Christmas Tree, and you’ll understand why my girlfriend suggested I need psychiatric help simply for owning it.

More to come….

This article is day one in a week of reporting articles.

If you are going to become a business intelligence ninja, start at the beginning. You need to develop standard procedures for report creation. They include:

• Who can request reports?
• Who approves their creation?
• Who assigns priority of your work?
• How are reports requested?

These questions are entirely determined by your corporate culture, however I would suggest writing up clearly defined procedures and sticking to them. As to how my users request reports, I use a standardized form for doing so. Mine is accessed from our intranet site. I can’t provide the page itself as it is owned by my employer, but it includes the following questions:

Please specify:

Report Title
Priority – 1 to 5 with 5 being most urgent
Please state purpose of report and give a brief description.
Can you provide an example? If so, please specify.
What file format does your data need to be? Printed Report, Excel, PDF, Web Page?
Report Layout: Portrait or Layout
Should the report have a chart or graph? Pie Chart, Bar Chart, Line Graph, etc?
Should the report be scheduled to run automatically? If so, please specify.
List the data fields, in the column order, for your report. Eg. Customer Name, Customer Number…
Does this report need to be sorted or grouped? If so what is the criteria?
What calculated fields do you wish to include in your report. Please be specific and include the formula for performing the calculation. Totals, subtotals?
Do you have any other comments or special instructions for your report?

Feel free to steal these and modify them in any way that suits you. The list of questions may seem exhaustive, but if you really think about it, this is the bare minimum of information one needs to know to create a basic report. Even with all of this information, all but the most trivial of reports will require further questions.

If at all possible, go directly to the source with those questions. If the VP of Finance wants the report, but asks the Accounting Manager to task you, try to ask your questions of the VP. I’ll expound on this Wednesday.

Be absolutely specific with your questions and assume very little. For example, when asking for the difference between two dates always ask whether they want calendar days or working days.

Users will often find this process laborious. Be polite and remind them that a thorough interview process will result in a better report in less time.

Do your report request procedures differ from mine? Any suggestions?

Tomorrow, I’ll discuss report layouts.

A good percentage of my day is spent writing reports. The report formats could be SQL Server Reporting Services (SSRS), Crystal Reports, M2M VFP reports, or ODBC Excel Spreadsheets. The latter three methods usually involve T-SQL, which I write by hand using TOAD for SQL Server or the SQL Server Management Studio (SSMS). In the past, I have searched the web for report design information, and didn’t find much. Anyway, each day this week, I will offer guidelines and suggestions I’ve learned over the years because I know many of you write reports as I do. For the most part, these will be general and not pertain to any specific report medium. Also, keep in mind that these are simply my guidelines for report creation. Your mileage may vary.

Day One – Requesting Reports
Day Two – Standardize Your Layouts
Day Three – Know What Your User Wants and Your Target Number(s)
Day Four – Exporting Reports
Day Five – Report Approval and Deployment

Dashboards are a hot topic these days and I need to investigate the available options. I had a Qlickview demonstration in person, but I’d like to talk to any of you who are using it.

So, are any of you folks using it? Would you mind telling me your opinions of the product?