We have an application that displays the customers as columns and our schedule for each of the customer. The time line is set as Rows and the Customers as set as columns. This display works fine, but the problem arises when there are 100s of customers - meaning 100s of columns in the calendar with 8am-8pm time line as Rows.
My question is if there is a limit on the number of Columns to be used in the calendars. We would like to see all the customers in one calendar and user should be able to scroll left and right.
If we select a few customers (10-15, even 20-40) and it works better (about 20-30% CPU usage. But when that range expands to over 100, the CPU is pinged heavily.
Could you please help.
There is no theoretical limit on the number of columns that can be displayed, but performance is going to be proportional to the number of columns. I don't think the original design ever anticipated quite that many being displayed concurrently, since in that case it might be difficult for a user to find a particular Owner.
We always strive to make the controls as performant as they realistically can be, so you might want to log an incident with Developer support so we can see if something can be done to improve performance in your scenario.
Thanks Brian. I have opened a support ticket for this, but i wanted to give you some addl info on what we are going.
Here is what we are trying to do:
- the calendar view is bound to a datasource to display technicians as columns
- we need to display the timeline (8am-8pm) as rows
- we need to display 800 technicians (Columns)
- and display about 3000 schedules across for the 800 technicians (not 3000 per tech, but in total)
- we need to set the Tool Tip also for each of the schedule
- to summarize, we will be seeing 800 technicians across with a total 3000 schedules
The first part of the actual CPU/Time consumption occurs when binding the datasource to a table containing 800 technicians. The second part is when we add 1 appointment at a time (for 3000 appointments) along with its tooltip.
Binding the datasource to the some 800 odd technicians is pegging the CPU about 90-95% and stays like that for almost a minute. BTW our system is a dual core Opteron with Win 2003/ SQL 2005 and/or SQL 2008.
Any suggestions as to what we need to look for.