All months of the calendar year

Question

I have a reporting requirement. I need to report the number of transactions made for each month for this particular calendar year.
I am using Crystal Reports 2008
Which is the best way to go around this - cross-tab or create the columns manually.
Some months may not have transactions still I need to report that month name and add as zero count.
eg:                            JAN FEB MAR
number of trans.        12   0      5
which is the best approach, please give details in both formats(crosstab as well as ordinary manual tables)
Thanks.

Answer 1

I agree with most of what Jason has said, but there are a few things that might be clarified a bit:
Adding 1 to the end date would be necessary if (a) the database field includes a time value as well as a date, and (b) if the end date parameter does not.  You would not want to do that if either of these two conditions do not hold, otherwise you'll be adding a day's worth of data to the report, perhaps unknowingly.  (Actually adding 1 might cause extra records to be selected if there is data for midnight the day after the end date, so you really should subtract a millisecond after adding 1, or force the time portion of the end date to 23:59:59.99999, which my preferred method, as it is obvious what you are doing.)
Sometimes CrossTabs can be a blessing, and make report writing a whole bunch easier.  Other times, they can turn into a huge pain in the neck.  It really depends on what you are trying to accomplish, what your data looks like, and what's easier to get from there to here.  If your requirements are for a grid of counts or sums with one (or a few) types of values (like month, year, product, whatever) going across the page, and one (or a few) types of data going down the page, a cross tab is probably the easiest way to go.  If the result needs to be more complicated, a regular report is often easier.  One rule of thumb that I use is "If you don't know at design time how many columns are required, go with a cross tab.  Otherwise, use a regular report."
And lastly, although I agree that the selection expert and other crystal tools can achieve anything that an SQL Command can do, run times are frequently much faster using a properly written SQL Command.  By pushing all of the record selection, table joins, and aggregation to the database, far less data gets returned to Crystal.  Databases are designed to do these types of tasks with great performance; Crystal is designed to do these tasks because it has to.  (That's a bit harsh, but having Crystal do these tasks will never be as fast as having a database do them.)  Also, if the database is not on the same machine as where the report is running from, you also have the issue of having to pump all of the data across the network.  Minimizing that data results in a much faster runtime.  Crystal does try to push as much of the work to the database as it can, but Crystal doesn't always do a perfect job of that (mainly because it has to do it in a general manner).
HTH,
Carl