Commented by: @dyemanov

The only way to report the more or less correct memory counters would be the following:

1) The record linked to MON$DATABASE always reports zeroes (it means that Classic has no shared cache)
2) The record linked to MON$ATTACHMENTS reports a total of both attachment and database specific memory pools

It somewhat breaks the idea behind aggregated counters (one might expect that a database pool counter would contain a sum of all its child pools), but this idea doesn't work in Classic anyway.

Another alternative would be to report proper memory statistics for attachments but random statistics for a database (instead of zeroes).

This is what can be done in v2.5. If you are not happy with that, a better solution will be deferred till v3.0.

Commented by: Douglas Tosi (douglasht)

I believe zeroed stats is less confusing than random.
Would superclassic behave this way too?
Would total memory used by the server be the sum of the memory used by all attachments?

Commented by: @dyemanov

Would superclassic behave this way too?
-- yes, as it doesn't have the shared cache either

Would total memory used by the server be the sum of the memory used by all attachments?
-- yes, approximately. There's a 64K memory pool (per process) not linked to any particular database, it won't be reported.