Does progress has a database tool which can monitor de sql statements firing on the database. I know promon has an option, but shows only the latest SQL statement. I would like to have one log file which contains the sql statements in a multi user environment. I need this because some statements causes a database lock.
Database SQL monitor
- Thread starter okion
- Start date
TomBascom
Curmudgeon
No. Progress does not provide such a tool (other than PROMON which you already know about).
On the bright side you are obviously running 10.1C or better. Congratulations! :biggrin:
Tell us more about these locking problems. If you're looking at SQL statements you must be using the SQL-92 engine and accessing the db via ODBC or something of that ilk. Usually that would be a read-only connection for reporting or inquiries. Is that what you are doing?
On the bright side you are obviously running 10.1C or better. Congratulations! :biggrin:
Tell us more about these locking problems. If you're looking at SQL statements you must be using the SQL-92 engine and accessing the db via ODBC or something of that ilk. Usually that would be a read-only connection for reporting or inquiries. Is that what you are doing?
Actually we are working on 10.2A.
About the locking problems....
We have some.Net processes. Some of them are creating views via ODBC sql.
When a view will be created a database lock occur. (-6 when I look via promon).
Normaly this lock is for a short period.
But when there are some multi users, some of these users will also get a database share lock. These lock will be there for a long time. When the connection will be broken, the lock will disappear.
When other users want to read also some data they get the database lock messages.
I discovered that when a view or table already exists when I try to create the view/table the lock will be also there for a long time.
When I close the conection the lock will disappear.
Is there a possibility to short the lock time, without closing the connection.
About the locking problems....
We have some.Net processes. Some of them are creating views via ODBC sql.
When a view will be created a database lock occur. (-6 when I look via promon).
Normaly this lock is for a short period.
But when there are some multi users, some of these users will also get a database share lock. These lock will be there for a long time. When the connection will be broken, the lock will disappear.
When other users want to read also some data they get the database lock messages.
I discovered that when a view or table already exists when I try to create the view/table the lock will be also there for a long time.
When I close the conection the lock will disappear.
Is there a possibility to short the lock time, without closing the connection.
No, it isn't a read-only connection.
At this moment the isolation level is READ COMMITTED.
We also tried to empty the isolation level again, but that gives the same result. ( This was a hack, which helped us with previous locking problems)
I think its a multi user problem.
I did some test and it looks like that when a select is started just before the view is created (or maby at the same time) and still running, the select will get an SHR database lock (-6).
That share lock will only disappear when i close the conection.
That explains why we do not get the database lock all the time.
At this moment the isolation level is READ COMMITTED.
We also tried to empty the isolation level again, but that gives the same result. ( This was a hack, which helped us with previous locking problems)
I think its a multi user problem.
I did some test and it looks like that when a select is started just before the view is created (or maby at the same time) and still running, the select will get an SHR database lock (-6).
That share lock will only disappear when i close the conection.
That explains why we do not get the database lock all the time.
TomBascom
Curmudgeon
BTW, the new and improved ProTop for .NET does support the 4gl stack trace capability in 10.1C and better. For SQL clients instead of a stack trace you get the SQL statement being executed. That might be helpful.
You need to go into PROMON and turn it on first.
You need to go into PROMON and turn it on first.
