ADOMD.NET - Microsoft SQL Server 2008 Analysis Services - page 614

If the number of milliseconds elapsed is greater than that specified by the Auto Sync
Period connection string property, the cache could be stale. (If this property is not speci-
fied in the connection string, ADOMD.NET uses 10 milliseconds as default value.) So,
ADOMD.NET sends an MDSCHEMA_CUBES request to the server to determine whether the
cube has been changed. If the cube has not been updated on the server during this period,
the object stored in the cache is passed to the client. If the cube has changed, however,
ADOMD.NET throws an AdomdCacheExpiredException .

When you are developing an application that works with metadata objects, you should be
ready to catch an AdomdCacheExpiredException and correctly process it. The
AdomdCacheExpiredException serves two purposes:

. To notify the client application that no metadata collection can be used until the

method RefreshMetadata is called on the AdomdConnection object.

. To enable the client application to update the user interface so that it reflects the

changes that occurred on the server. For example, if your client application shows a
tree of the metadata objects and one of the dimensions has been renamed on the
server, you would want to refresh the tree view to reflect the name change.

Working with a Collection of Members ( MemberCollection )

The collection of members differs radically from other collections that contain metadata.
The main distinction is the potential size of the collection. Even the number of dimen-
sions, hierarchies, and levels that you would find in very large systems can be measured in
hundreds or thousands, but this information can easily fit in the memory of the client
computer. On the other hand, the number of members at the bottom level of one dimen-
sion could easily reach millions. If we load all the members of that level on a client's
computer to cache a collection of members, we could easily overload the client computer.

A correctly designed client application, however, doesn't demand all the members of a
level simultaneously. Usually the client needs only enough members to fit the screen of
the user (or two screens, if you want the application to read a little bit ahead and prepare
the data in advance for the next display).

If you want to show a limited number of members, there is no need to bring all the
members of the level to the client computer. The client application does not usually
really need all the information contained in all 20 columns of the MDSCHEMA_MEMBERS
schema rowset. (Most of the time, the properties you'll want are Name , Unique Name ,
Caption , and Type .)

To meet the needs of the typical developer who doesn't want all those properties,
ADOMD.NET provides an interface for access to a subset of members. There are four over-
loads for the functions Level.GetMembers and Member.GetChildren , which return
MemberCollection . Because the operation of loading members can take a significant
amount of time, the ADOMD.NET designers created this interface such that, unlike the
other interfaces for access to collections, MemberCollection is retrieved by the method
instead of by the property.

. Level.GetMembers() returns all members of a level, with a limited set of properties.