Hi tech guru's,
I am using the infragistics 8.1, which is a recent version. I am implementing the webschedular for my project.
In my case, I have a database structure which is quite different from what is provided for the webschedular as example, I have a different set of field names. So, I started with building my custom webschedulesqlclientprovider for my custom stored procedures. But the functionality of my webschedular is similar to what is provided or meant for.
I am trying to understand, what are the objects am I supposed to customize, Should I customize only the webschedulesqlclientprovider or should I customize the
If I have to customize the webschedulesqlclientprovider only, where can I define which stored procedure it is supposed to use.What is the step by step process?
Please let me know if there are any sample code that is provided.Note: I tried the article "Creating a custom data provider" in the infragistics help.
I created a project as defined in the above article, but could not figure out how to move forward from there.
Any help is greatly appreciated.
ThanksSai
Ok, we can´t modify the parameters in the Stored Procedures, so, if we need to use a more complex query with more parameters we need to use a SQLDataSource with UseStoredProcedures = False, but than returns an error "isnull function requires at least 2 arguments". Do you have any idea or samples on using "UseStoredProcedures = False"?
Thanks
Hi I got it connected to the database. I used the following code to connect it.
private void InitializeComponent() { this.WebScheduleSqlClientProvider1 = new Infragistics.WebUI.Data.WebScheduleSqlClientProvider(); WebScheduleSqlClientProvider1.DataSourceID = "SqlDataSource1"; SqlDataSource1.ProviderName = "System.Data.SqlClient"; SqlDataSource1.ConnectionString = ConfigurationManager.AppSettings["Connection1"] + Session["databasename1"].ToString(); }
I am getting error when trying to set the sqldatasource connectionstring property at run-time. I use different databases and need to assign the connection accordingly. I am using ASP.NET 2.0, SQL Server 2005 and Infragistics v 8.1 and have the following code working.
<igsch:WebScheduleInfo ID="WebScheduleInfo1" EnableSmartCallbacks="true" runat="server" EnableRecurringActivities="True" OnActiveDayChanging="WebScheduleInfo1_ActiveDayChanging"> <ClientEvents ActivityUpdating="WebScheduleInfo1_ActivityUpdating" ActivityAdding="WebScheduleInfo1_ActivityAdding" /> </igsch:WebScheduleInfo> <ig_scheduledata:WebScheduleSqlClientProvider ID="WebScheduleSqlClientProvider1" runat="server" DataSourceID="SqlDataSource1" WebScheduleInfoID="WebScheduleInfo1"> </ig_scheduledata:WebScheduleSqlClientProvider> <asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="<%$ ConnectionStrings:EMO_ConnectionString %>" SelectCommandType="StoredProcedure" SelectCommand="Activity_Sel"> <SelectParameters> <asp:SessionParameter Name="ResourceName" SessionField="ResourceName" Type="String" /> </SelectParameters> </asp:SqlDataSource>
but when I assign it in run-time in Page_Load(),
SqlDataSource1.ProviderName = "System.Data.SqlClient"; SqlDataSource1.ConnectionString = ConfigurationManager.AppSettings["Connection1"] + Session["databasename1"].ToString();
it shows the following error and I don't have a database named WebSchedule1.
Cannot open database requested in login 'WebSchedule1'. Login fails.Login failed for user 'sa'.
Can anybody help me...
Thanks Derek. It's a little disappointing that we can't easily modify those, but its good to know when to cut your losses I guess. I assume that means we also can't modify the names of the stored procedures? Any chance these will be exposed in the future?
See this help topic. DataBindings only pertain to dynamic SQL (that is where the data provider writes SQL statements on-the-fly). DataBindings cannot work on stored procedures because they are compiled by your DBMS, granted permissions by your DBA, etc.
What you can do is modify the field names in the stored procedures, the SQL for which are included and usually it's just a matter of some global search and replacements.
I wouldn't suggest modifying the stored procedure's parameter names, if they don't match the contract expected by the data provider then I think the SqlCommand will throw an exception. They are not exposed anywhere (at least, anywhere that would be easy to change).