In MS Outlook VBA, how does the structure of a Table object make a row count unreliable?

The Table object does not have a property count. Instead, it has the method GetRowCount. But that comes with the warning that it’s not reliable and may return an approximate count and yield an error.

Does anyone here know what’s different about the structure of a Table object that prevents VBA from knowing its count?

>Solution :

The GetRowCount method corresponds to the IMAPITable::GetRowCount method which explains possible reasons like memory constraints and etc. You may find the following description helpful:

Use GetRowCount to find out how many rows a table holds before making a call to the IMAPITable::QueryRows method to retrieve the data. If there are less than twenty rows in the table, it is safe to call QueryPosition to retrieve the whole table. If there are more than twenty rows in the table, consider making multiple calls to QueryPosition and limit the number of rows retrieved in each call.

Some tables do not support GetRowCount and return MAPI_E_NO_SUPPORT. If GetRowCount is not supported, an alternative might be to call IMAPITable::QueryPosition. With the results from QueryPosition, you can determine the relationship between the current row and last row.

When GetRowCount returns MAPI_E_BUSY because it is temporarily unable to retrieve a row count, call the IMAPITable::WaitForCompletion method. When WaitForCompletion returns, retry the call to GetRowCount. Another way to detect whether an asynchronous operation is in progress is to call the IMAPITable::GetStatus method and check the contents of the lpulTableState parameter.

In Extended MAPI (a low-level API on which Outlook is based on) you can specify how many rows you would like to get using the IMAPITable::QueryRows method.