Devart Forums

Hi:

What are these cursor objects that are displayed under the connection object in the Object tree?

I assumed that the Connection node (in the Object Tree) corresponds to the TSQLConnection object in the app. I am however confused by the Cursor objects.

I have the following scenario:
1. Connect to oracle as user1
2. Run query1 (using TSQLStoredProc)
3. Disconnect
4. Connect to oracle as user2 using the same TSQLConnection object as at step 1
5. Run query2 (using TSQLQuery)

In the dbMonitor query1 & query2 appear associated with the same cursor. I found this confusing and I was hoping that you could clarify what a cursor is in this context and why two queries run in different sessions appear under the same cursor. The cursors in the dbMonitor doesn't seem to correlate with the information returned by the v$open_cursor view.

I also looked in the dbMonitor help and there is no specification of cursors.

Thanks!

Update: After more testing with a second app in debug mode, the dbmonitor created a second connection object, even though we use a single TSQLConnection object. So, at this point, I am not sure the Connection nodes in the Object tree map to the TSQLConnection object.

Another related issue - the TSQLMonitor.Active property setting (true/false) does not seem to control anything.
The documentation says:

Starts or stops the monitor from recording SQL commands passed to the database server.
Set Active to true to start monitoring the communication between SQLConnection and its database server. Set Active to false to stop the monitoring.

In our environment the output to DBMonitor GUI happens regardless of the setting of this property. In order to truly dosable this we have to blank the TSQLMonitor.SQLConnection property. A bug?

We have reproduced the problem with events display in DBMonitor even when SQLMonitor.Active = False - and we will investigate the reasons for such behavior.
Please describe the first problem in more details.

I don't have anything to add to this. My questions required some clarification about what we see in the dbmonitor.

In the new Delphi versions, behavior on using SQLMonitor was changed. The Callback method was registered only when the Active property was set to True. Now, it is registered not depending on this property value. And since check is performed by availability of this callback method - the message is always sent.