Including filters in custom load methods to load collections

When a custom load method is used to load a collection, the system does not automatically apply the filters defined for an IDO. This means that you must explicitly implement any filtering within the custom method. Before you implement a custom load method, you should be very familiar with the IDO definition.

If the method defines a specifically-named parameter, the system passes the currently active filter to the method. For methods that are hand-coded in .NET, this parameter must be named IdoFilter and it must be of type String. For stored procedure methods, this parameter must be named @IdoFilter and it must be of type nvarchar(max). This must be the last parameter listed for the method.

However, when you specify method parameters in the IDO metadata—that is, by using the development forms IDOs, IDO Methods, and IDO Method Parameters—or in Design mode, you must not provide this filter parameter. It is an implicit parameter that the system satisfies if it exists; however, if the parameter does not exist, the method still works. There is no logical value that can be specified in the IDO metadata or in Design Mode for the filter parameter, since it varies, depending on who is logged in, which groups they are members of, and so on.

The filter that is passed is a fully-parsed, valid SQL filter. The filter can be appended with a conjunction to the WHERE clause of a query, or the filter by itself can be the entire clause for the query. However, since the filter can refer to any table referenced in the IDO definition, you must make sure that any tables referenced in the filter are present in the query.