Progress® Telerik® Reporting R2 2017

Configuring the database connectivity with the EntityDataSource component

This section discusses how to specify a database connection to the EntityDataSource component that can be used both at design-time and when running the report in production. The provided examples and code snippets assume an existing Entity Data Model of the Adventure Works sample database with the following structure:

Strictly speaking, it is not necessary to specify a database connection when working with the EntityDataSource component. Simply specifying an ObjectContext/DbContext and a member is enough to connect to the Entity Data Model, because the ObjectContext/DbContext is already configured to access the database. The following code snippet shows the minimum code necessary to setup the EntityDataSource component:

var entityDataSource = new Telerik.Reporting.EntityDataSource();

entityDataSource.Context = typeof(AdventureWorksEntities);
entityDataSource.ContextMember = "Products";

var report = new Report1();

report.DataSource = entityDataSource;

When running the report in production the above code should work just fine. However, this is not the case when generating a preview of the same report in the designer, for example. The problem is that the ObjectContext/DbContext searches its connection string in the configuration file of the current executing application or web site. When it is your application that is currently running, all that is necessary is to make sure the connection string is present in the right configuration file. On the other side, when running the report in the designer, the current executing application is Microsoft Visual Studio, so the connection string is no longer available. To overcome this, you can specify your connection string to the ConnectionString property of the EntityDataSource component, as shown in the following example:

Note Note
When using DbContext by default the context class generated (Database First or Model First) provides only a default (parameterless) constructor. However for design time purposes a constructor with connection string (string argument) is needed so that while processing the report the correct connection string can be passed. If Code First is used there is no need for a constructor with string parameter. That is because this approach uses connection strings without metadata (which is needed for the mapping). This means that the connection string of the context can be directly set to this connection string, without the need to be resolved first. Adding the needed constructor is as simple as it is adding the snippet below:
partial class AdventureWorksContext
{
  public AdventureWorksContext(string connectionString) : base(connectionString) {}
}
Telerik.Reporting.EntityDataSource entityDataSource = new Telerik.Reporting.EntityDataSource();

entityDataSource.ConnectionString = "AdventureWorksConnection";
entityDataSource.Context = typeof(AdventureWorksEntities);
entityDataSource.ContextMember = "Products";

The ConnectionString property can accept an inline connection string or the name of an existing connection string stored in the configuration file. When running the report EntityDataSource searches the configuration file for a connection string with the specified name. If such connection string exists EntityDataSource uses that connection string to connect to the database otherwise it is assumed that the value of the ConnectionString property represents an inline connection string.

Note Note

Specifying an inline connection string directly to the ConnectionString property of the EntityDataSource component is not recommended, because it might be difficult to maintain all your reports later, when that connection string changes. The recommended approach is to always specify the name of an existing connection string stored in the configuration file. When specifying a connection string form a configuration file it is important to understand which configuration file is used at design-time or when running the report in production. For example, let us consider the following simplified structure of a business application:

The above schema assumes that the different parts of the business application are represented as separate projects in the solution, each with its own configuration file. Initially, when you create the Entity Data Model in the Business Logic project, the connection string is stored automatically in the configuration file of that project. Later, when creating new reports in the Report Library project, you need to add the connection string to the configuration file of that project, because this is where Report Designer searches for existing connection strings. Finally, when deploying your application or web site in production, you need to add the connection string to the configuration file of your Main Application.