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.