I make extensive use of Form and List modules but have hit a real performance issue - around 90 seconds to load a page - with a list of only 1000 rows. (There are under 20,000 entries in the user defined data table). Each row in this particular list corresponds to attendence at an event by a family, and contains links to each family member and to some qualifications from their User Profile.

So, most of the columns look-up Users or get elements from UserProfiles. This is understandably slow (with the current database structure - I have some longer term ideas for improvements based on replacing the ntext value field with indexed lookups).

On our site, there are hundreds of filtered views of this module, where each view filters to a single event and typically might return just 10 rows, corresponding to 10 families.

I understand that the UDT module builds a complete dataset in memory in order to support searching, sorting, etc. I am looking for a way, behind the scenes, to populate the dataset with just the rows I want, and am happy that searching and sorting will only be on these rows.

I strongly suspect that if the SQL Server stored procedures for the UDT module included TabModuleID as a parameter instead of, or in addition to, ModuleID, I could change the stored procedures to just return the rows I want for each view of the module. This is because the TabModuleID is the key to the TabModuleSettings as well as linking to the ModuleID. I can pretty easily modify the SQL to suit given the TabModuleID as a parameter.

Does this make sense, and if so what are the options for requesting a change to the module, or getting my hands dirty with VB code changes? I am not sure yet where to find the code that invokes the SQL stored procedures to build the dataset.

Thanks, Richard

Hi Stefan and thanks for your very quick reply.

Not sure I understand what you mean by "you did add a field ... to the table definition". I have not changed any definitions, and a simple look up on the TabModule table can find ModuleID given TabModuleID and vice versa.

The suggestion to replace ModuleID with TabModuleID in the stored procedure calls is not really a special use case, since every invocation of a module is always from a Tab and is therefore associated with a TabModuleID. It would be a very small overhead to get the ModuleID from the TabModule table inside the stored procedure, but would give an enormous benefit to those who want to 'tune' the behaviour at the database level without changing source code. The bottom line for me is that there is no need to read in the entire content of the module when there is a filter, since the filter cannot be changed by the user and all the subsequent sort and search operations only operate on the filtered subset.

For me, it it easier to implement a filter at the database level (and faster).

Next dumb question is where can I find the definition of DataProvider.Instance().GetRows(ModuleID)?

Many thanks, Richard

Richard, sorry, this change would return the very same amount of data as before.