searches for existing database connections in Server Explorer
and in the configuration file of the current project. For example, if you have a separate class library project for your reports, the wizard searches for connection strings only in the App.config file of that project. If you have your connection string specified in the Web.config file of another project, you need to copy it to the App.config file of the report class library as well, otherwise the wizard cannot discover it. This is done for a reason: since a solution may contain many different projects, each of them with its own configuration file, it is unknown which one might contain the correct connection string for your report, so we simply pick the configuration file of the current project where the report is located. Moreover this behavior allows you to use two different databases for development and for production. For example, the database used for development and testing purposes might be a local one, while the actual production database might be situated on a dedicated database server.
Regarding the fact that connection strings for Windows applications and class libraries are stored in the Settings.settings file as well as the App.config file, while for web applications the connection strings are stored only in the Web.config file - this inconsistency is caused by Visual Studio which treats different project types differently (not to mention web sites which are not treated as projects in Visual Studio at all). For instance, you can experience exactly the same inconsistent behavior if you add a typed DataSet and choose to store the connection string in the configuration file. SqlDataSource Wizard simply uses the same design-time services that Visual Studio exposes to all designers, so we are consistent with this inconsistency as well.
the Telerik team
Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>