RDL Project  

This page is now fairly up-to-date. It was outdated for quite some time. This feature has limited usefulness and is only for very advanced users.

Report Definition Language (RDL) is a non-proprietary report format being promoted by Microsoft to encourage interoperability of reports between different programs. It happens to be a very good format. This is not for beginners. You need to have a basic understanding of SQL queries and XML.
Microsoft Website
Specification in PDF format (version 2)

RDL Project is a reporting program that has been integrated with Open Dental for a long time. Very advanced users can try it out. To use it, open RdlDesigner.exe, which is located in C:\Program Files\Open Dental\ or similar. Create your report, and save it. To later run your report, open the Rdl Designer again, open your report, and run it. To run reports directly from within Open Dental, save them to \\SERVER\OpenDentImages\Reports (or similar, your A-Z folder). It will also later be used to handle printing and exporting existing reports. RDL is similar to programs such as Crystal Reports, with the following exceptions:

RDL format is far more powerful and flexible, because everything is in nested heirarchical levels.
The report files are in XML rather than a closed proprietary format.
RDL Project is written in C#, the same language as Open Dental, so integration is very easy and complete.
RDL Project is open source, so we have total control and can change anything we want.

Here's the getting started page distributed by the RDL Project.

Using Code In Reports

Code is used in reports for a number of purposes, including:
1. To make the returned data human readable.
2. To reduce the complexity of reports.
3. To provide data that is organized according to the unique needs of Open Dental.

To use code in reports:

The file called ODR.dll is in the same folder as RdlDesigner.exe. ODR is short for Open Dental Reporting and is created by us. It contains a set of functions that can be used as explained below. It will be continually improved and added to, and the version number will always match or be similar to the version of Open Dental. To obtain the version number, right click on ODR.dll and select the version tab.

Here are some of the main classes within ODR: MakeReadable, Query, Format, Aggregate, and GetData. Each of the classes has (or will have) many functions for the specific column type you are working with.

If you are using any functions at all in your report, then you need to add ODR.dll as a code module. To do this, in the designer, right click in an empty area of the page, and select Properties.

In the Modules tab, add ODR.dll as shown above. This instructs the report to use ODR.dll for functions. The Classes portion of the above window is discussed below in the Instance Functions section.

A function will look similar to this, when used in a text box:
=ODR.MakeReadable.PatStatus(Convert.ToString(Fields!PatStatus.Value))
MakeReadable.PatStatus is the function. Fields!PatStatus.Value is the field which gets passed to the function.

List of Functions, as examples
=ODR.MakeReadable.PatStatus(Convert.ToString(Fields!PatStatus.Value))
=ODR.TestValue.AccountDebitIsPos(Convert.ToString(Fields!AcctType.Value))
=ODR.Format.NumberHideZero(Convert.ToString(Fields!DebitAmt.Value))
=ODR.Aggregate.RunningSum(groupByValue,valueToAdd)
   Example:  =ODR.Aggregate.RunningSum(Convert.ToString(Fields!AccountNum.Value),Convert.ToString(Fields!DebitAmt.Value))
=ODR.Aggregate.RunningSumForAccounts(Fields!AccountNum.Value,Fields!DebitAmt.Value,Fields!CreditAmt.Value,Fields!AcctType.Value)
=ODR.DataConnection.GetODConnStr()
=ODR.GetData.Pref("PrefNameGoesHere")
   Example:  =ODR.GetData.Pref("PracticeTitle")

Instance Functions
Note: Instance functions seem to be broken in the current version. Not sure why. The workaround is simply to use a more complicated query.
A few functions need to have some actions performed when the report first opens and before any data is retrieved. For instance, when converting PatNums to readable names, all patient names need to be retrieved from the database at the very beginning. That way, as each patient name is needed, it is already in memory and can be quickly retrieved. This is faster than repeatedly querying the database for each individual patient name as needed. For these situations, extra classes are used, such as the one called MakeReadablePatNum. Each of these classes has one function called Get which is used throughout the report. If you are using an instance function, you must the classname and instance name as shown in the screenshot of the Report Properties above. If there is more than one instance function, then each needs to be added.

An instance function will look similar to this when used in a text box:
=MakeReadablePatNum.Get(Convert.ToString(Fields!PatNum.Value))
Fields!PatNum.Value is the field which gets passed to the function.

List of Instance Functions, with examples
MakeReadablePatNum.Get
    =MakeReadablePatNum.Get(Convert.ToString(Fields!PatNum.Value))
Query.Get
    (see below)
Query.GetParameterValue(name)
    =Query.GetParameterValue("startdate")

Parameters

The old complicated way of doing parameters was moved out to its own page Old RDL Parameters.

First you need to be aware that there are two types of parameters: report parameters and query parameters. Report parameters are defined in the designer using the Report Properties dialog. Report parameters can be used just about anywhere an expression is allowed in the report. Query parameters allow you to use pass arguments to a dataset most usually as a parameter in a SQL Select. Query parameters are defined in the Dataset property dialog. Your example select would look something like this:
SELECT * FROM items WHERE items.Code > @QParam
Frequently, a report parameter is used in to define a query parameter. If that was the case then 'QParam' might be defined as the expression =Parameters!RParam.Value
If you're creating a report using the designer wizard the wizard assumes that you might be using the parameters in the query and automatically builds Query parameters for each Report parameter you define. This allows you to directly place '@P1' in your request.

For programmers, here's how we (will) use parameters in code. We will typically build our own user interface for setting the parameters. The code below was supplied as an example by the writer of RDL Project. Some adaptation of it will probably be used.
viewer1.ShowParameterPanel = false;  // don't use builtin UI
Report r = viewer1.Report;
ICollection parms = r.UserReportParameters;
foreach (UserReportParameter urp in parms)
{
// put some code here to process the parameters
//   either retrieving the values or setting them
}
If we do this right, users will be able to use their own custom RDL reports based off of our built-in ones.

Future Improvements

RDL reporting has tremendous potential. You should see improvements in each version. Here is the approximate order in which improvements will be made:

Implement improved parameters.

Support for more enumeration types in MakeReadable functions.

Option to set some parameters from outside the report and bypass the parameter dialog. For instance, Open Dental needs to print an Rx, so it would pass the RxNum to the report. The report should then not make the user pick from any options, but should just use some queries to get all the necessary data directly from the database. So one parameter is needed, but it should be suppressed somehow; silent.

Testing the use of programming logic within reports.

Users allowed to organize their reports and to pick which reports to use in various places in the program.

Ability to use images in reports. The images could be specified either through parameters, or as the result of queries.