Often it is a requirement to design a report against a development database and then switch the connection at runtime. This can be done in many ways with BIRT. The options include:
JNDI - Look up the data source.
Property Binding - Swap the data source at runtime using property binding expression.
Script – Write a script in the beforeOpen event handler to modify the data source properties.
Connection Profiles – Store the connection information in a shared profile.
DTP driverBridge extension – Implement a driverBridge extension to intercept calls to a specific driver.
Design Engine API (DE API) - Swap the dataset property on a specific table before running the report.
Using the DE API often serves as a useful alternative, because the data sources may be different types. For example your deployed report may use a scripted data source to retrieve some EJB value, but at design time you may not have access to this data source. So you could develop a stubbed data source that uses JDBC to test your report layout and when deployed swap the data set on elements that are bound to the data set. To do this you need to do a few things. First name your elements that use the data set to be swapped. This can be set in the general properties for each report element. Next make sure your two data sets (one for design time and one for deploy time) have the same result columns. If the result columns are not the same much more work needs to be done in order to implement this solution. Finally implement a beforeFactory script that modifies the report design before it is executed. Assume we have two data sources/data sets and one table. If I name my table “mytable” and my data sets are named “viewer” and “designer” the beforeFactory event script would look as follows:
des = reportContext.getHttpServletRequest().getParameter("__designer");
if( des == null || des == "false" ){
mytable = reportContext.getReportRunnable().designHandle.getDesignHandle().findElement("mytable");
mytable.setProperty( "dataSet", "viewer" );
}
Note that the “designer” data set is the default data set used in the report. This is the data set that you should drag to the canvas to build your report
The first line of code determines whether we are using the designer. The designer adds the __designer parameter to URL when the report is previewed. This parameter will not exist when deployed. If this parameter does not exist or is set to false we assume that the report is deployed. This line:
reportContext.getReportRunnable().designHandle.getDesignHandle()
returns the report design handle. BIRT 2.3 has an easier way of getting the report design, but this method should work for BIRT 2.2 and 2.3. We then use the report design handle to locate the table element to be modified. Finally we set the dataSet property to the viewer dataset.
An example report illustrating this concept is located here.
DZone has just released the first set of their 
We admit it, we're proud of our design. But it's much more than just eye candy, as we believe that people work better when they work with something that pleases the senses. The pretty face of Ma.gnolia doesn't sacrifice usability, either. We place a premium on being easy to understand for people who don't know or care about how something works - they just plain want it to work.