unexpected table lock

Hi all, my question is related to table locks caused by the job of the DBSA. With dbaccess Query-Language/Info/Status I wanted to display the number rows of a very big table. I got the message that the table was locked. So I set lock mode to wait and again called the Status. Some time later I got the answer from Status: 171 Mill. rows. The fatal was that some oltp applications produced errors because now these application got lock errors. More fatal was that one UNIFACE application which has to sum up the value of a field of the table in question and write the result to another table wrote the value "0" to all resulting rows though in transaction. The question is: Which kind of lock is implied by Query-Language/Info/Status or "select count(*) from table"? In my opinion the DBSA has to be able to monitor the status of a table at all times. How do you think about it? Reinhard.

>> In my opinion the DBSA has to be able to monitor the status of a table at all times. >> How do you think about it? if that is the case and your apps fall over then: set isolation to dirty read; before you access tables. dependant on the logging mode of the db (informix logged (Un)Buffered will give to commited read isolation level... Ansi will give you repeatable read.... YUK...) Superboer.