I must have got the wrong attachment id because it all seemed to be working
when I tried again. -:)

2009/4/20 Huan Ruan <leohuanruan@...>

> Just observed that
>
> delete from mon$statements
> where mon$attachment_id *= [AnotherAttachment]*
>
> works with Windows but not Linux.
>
> delete from mon$statements
> where mon$attachment_id *<> current_connection*
>
> works with both Windows and Linux.
>
> I assume that's not as designed, is it?
>
> 2009/4/20 Huan Ruan <leohuanruan@...>
>
>
>> Thanks for the reply, Helen.
>>
>>>
>>>
>>> 1. You could only do that if you called it from a login that was either
>>> SYSDBA/root or the same *Firebird* user as that which owns
>>> [AnotherAttachment]
>>>
>>
>>
>>>
>>> I used the database owner login in all the connections. And I just tried
>>> with SYSDBA but still no luck.
>>>
>>
>>
>>>
>>> 2. A statement can't be cancelled if it is not active. Monitoring runs in
>>> a transaction. This means that a statement that's inactive at the time your
>>> monitoring transaction starts [think "started"] will be invisible. So commit
>>> your old monitoring transaction before trying to do something fresh.
>>>
>>
>>> I run the cancel command while the query is still active/running, i.e.
>>> before it returns any results. The same experiment with Windows did work,
>>> while the Linux one the query just kept running.
>>>
>>
>>
>>>
>>> Otherwise - maybe that bad statement simply beats you to it
>>>
>>
>>
>>
>>
>>>
>>>
>>> ./hb
>>>
>>>
>>>
>>
>>
>

[Non-text portions of this message have been removed]