If the WebSchedule DB provider is trying to use its default connection string, then the connection string it has must be invalid.  Usually a connection string is passed to the provider by setting it to use a SqlDataSource or AccessDataSource control on the page.  The provider examines the data source control, and uses its ConnectionString (the DB provider uses nothing else from the Data Source control).

When controls are scattered across a Master Page or User Controls, the ID of your SqlDataSource or AccessDataSource is going to be munged with the names of any parent containers, and some special characters like '$' and '_'.  So if you set the plain ID of the data source control (like "AccessDataSource1") then it won't be found (since there could be other controls named "AccessDataSource1" in other containers on the page,  in fact your AccessDataSource1 in situations like this is really named something like "ctl0_ctl11_MyControl_AccessDataSource1").  You can use the analogy of phone numbers and area codes: 555-0246 could be one phone in Los Angeles, another phone in NYC.  But 310-555-0246 and 212-555-0246 identify a specific phone without ambiguity.  The WebSchedule DB providers need a Client ID that is similarly specific to reliably find the Data Source control when used on Master Pages or User Controls.

If you're having difficulty setting the data source control and connection string to use dynamically, you can call the Connect method on the WebSchedule DB provider to pass in the connection string you want to use at run-time.  It will then create an ADO.NET Connection to the database you give it instead of falling back to the default.

I believe this to be a bug, but have a work around you can try out that worked for me. Here's the steps to success:

1. Drop WebScheduleInfo onto the Design view.
2. Drop WebScheduleSqlClientProvider next to the WebScheduleInfo.
3. DO NOT SET a DataSourceID for the WebSceduleSqlClientProvider, but make sure you have the WebScheduleInfoID referencing the WebScheduleInfo you dropped in the first step. (Note: For some reason if you reference a connection string with WebScheduleSqlClientProvider when your calendar is being used on a content page of a master page it will *always* fail to connect to the datasource).
4. Drop a calendar or any of the schedule controls into the design page view. Make sure its WebScheduleInfoID is set to the WebScheduleInfo from the first step.
5. Right click in design view and click on View Code. Paste the code below into your Page_Load event.

WebScheduleSqlClientProvider1.Connection.ConnectionString = ConfigurationManager.ConnectionStrings["SweetSuccessConnectionString"].ConnectionString;

Be sure to change the connection string name to whatever it's called inside your Web.Config file. Now view the page in the browser and watch the magic happen!

Your code shows one way of setting the Connection.ConnectionString on the WebScheduleSqlClientProvider.

Two other ways the data provider can be told how to connect to the database are by setting the DataSourceID (which the data provider uses to retrieve the Connection String, however as described this will not work unless the fully-qualified ID of the Data Source control is used), or passing the connection string at run-time by the Connect method.

If you do not tell the data provider how to connect by one of the available means, it can't connect.