Programming Guide - Actian

How Running in the Debugger Environment WorksHow Running in the Debugger Environment WorksThis section describes how the OpenROAD Debugger affects a runningapplication's environment.Frame StatesWhen you are running an application and using the OpenROAD Debugger, thebehavior of the application may differ slightly from the behavior when theDebugger is not in use.For example, in a running application, any changes to a frame that occur in anevent block (data changes or visual property changes) are visible after theevent block completes. However, when you use the Debugger to step throughthe code, you see such changes when the actual statement that causes thechange completes. Therefore, you might see the frame in a state that youwould not see in a free-running application.TransactionsWhen you use the Debugger, you can stop the execution at any point.However, if you stop execution in the middle of a transaction, it may affectothers' ability to work in the database because a transaction holds the locks itinitiates until it is finished.ErrorsWhen an error break occurs, the application is in an indeterminate state. Thebreak occurs at some point in the execution of the statement that caused theerror, but it is impossible to determine exactly where. This means, forexample, that any expression you examine might not show the expected orcorrect value.Application Threads and Thread IdentifiersWhen you start an application, you open the first thread. Each time thereafterthat your application issues an openframe statement, it begins a new thread inthe application.Generally, the user remains unaware of these individual threads in anapplication. However, when you use the OpenROAD Debugger, you must beaware of which thread you are working on, especially if your application usesthe openframe statement to open several instances of the same frame.444 Programming Guide