The MON$STATE is being shown as Active even if no CPU usage is happenening. In fact it remains Active while the statement is open, but even while it's idle, giving wrong information about statements that could be consuming resources.

  An example: If I run a query, the statement is set as active, and the query appears in the MON$STATEMENTS table. Also the MON$TIMESTAMP is set. During some instants the query runs, then it returns the result, with the cursor in the first data register. BUT, if I stay stopped, without retrieval of the data (let's say user left table open and left for lunch...) even not consuming any processor, the query remains Active, and the timestamp unchanged. The MON$STATE only returns to Inactive when the user reaches the last data page, or if the transaction is ended!

  The effect is that if I perform some monitoring during such interval, while the query is open but idle (waiting the user request for more data), checking MON$STATE as active and the value of MON$TIMESTAMP it will appear that we have an endless query - while it may be a just normal an valid query. And we will not be able to identify witch query in that instant may be the one that is really consuming the processor...

  I would expect that MON$STATE (and MON$TIMESTAMP) would flag the statements really consuming CPU, to help us to identify what tasks may be consuming the server resources (processor!), and that it should be inactive when the statement is idle. It can work well for web apps that retrieve data immediately after the query and in sequence close the transaction, but in scenery where there are many desktop clients, we may have many active statements even if none of them are really consuming the processor resources.

  In an ideal world, as a suggestion, we could have FOUR STATES: 0=Inactive; 1=Active during query processing; 2=Idle after processing select, but before reaching end of data and releasing the statement; 3=Active during data retrieval. Of course a second MON$TIMESTAMP should exist to show the time when the last CPU usage started (states 1 or 3, which actually means "using CPU") - this would be the timestamp to be checked to find the statement consuming CPU. Another benefit of this would be to identify time consuming queries (a lot of time in state 1) or fast queries but with excessive result set (too much time in state 3). Notice that it's possible a statement return from state 3 to state 2, then to 3 again, several times, if user gets data in blocks, until the user finishes to retrieve data (returning then to state 0).