Connection Information

To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.

Connection Type

Troubleshooting a distributed PowerBuilder application – PB Docs 70 – PowerBuilder Library

Troubleshooting a distributed PowerBuilder application – PB Docs 70

Troubleshooting a distributed PowerBuilder application

Testing locally

Like a traditional PowerBuilder application,
a distributed PowerBuilder application can be tested on a single
computer. You can test your application by running it in a single
process, either in test mode or debug mode, or by running a single
executable (EXE) file. Alternatively, you can test the client and
server applications in separate processes, where at least one is
an executable file.

Using the Local driver

PowerBuilder provides a Local driver that lets you test a distributed
application without having to use one of the standard communications
protocols. This allows you to test a large part of your work without
being concerned with the network configuration on which the application
will be deployed. You can use the Local driver on all platforms.

One of the biggest
advantages of testing applications with the Local driver is that
this approach allows you to use the PowerBuilder debugger to identify problems
in your code. When you run an application in a distributed environment,
you cannot use the debugger to examine the behavior of the server
application.

Using the trace facility

PowerBuilder provides
a trace facility to help you identify and fix problems that may
arise once an application is running in a distributed environment.
The trace options allow you to monitor client/server communications
by logging system activity to a console window or to a file. You
can use the trace facility in both the client and server applications.

Testing with the Localdriver

If you want to use the
debugger to identify problems in both the client and server components
of a distributed application, you need to test the application with
the Local driver.

note.gif Local driver not supported with Version 7 Proxy objects You cannot use the Local driver to test a distributed application
if you have Version 7 Proxy objects in the library list for the
application.

No Transport object required

When you test an application with the Local driver, PowerBuilder handles
all requests for remote services by emulating the server. Because PowerBuilder takes
care of all communications functions normally handled by the Transport object,
the application does not have to create a Transport object or perform any
of the activities associated with using the Transport object.

Local driver uses a single process

When you use the Local driver, your application runs in a
single process. This restricts the client and server components
of your application to the same variable context and name space,
which may lead to usage conflicts.

Example

The following script shows how to establish a client connection
by using the Local driver. The script instantiates the myconnect
Connection object and sets the Driver property of the Connection
object to identify the Local driver. Then the script invokes the
ConnectToServer function to establish the connection. Notice that
the script does not set the Application and Location properties
of the Connection object; these properties are not required with
the Local driver:

Running the debugger

When you test a distributed
application with the Local driver, you have access to the full range
of debugging features available with PowerBuilder. You can set stops
(breakpoints) in scripts, step through the code line by line, and
display the contents of variables. When you run your application
in debug mode, PowerBuilder stops execution just before it hits a
line containing a stop. You can then look at (and change) the values
of variables.

For more information about running in debug
mode, see the PowerBuilder User’s Guide
.

Testing locally witha communications driver

You can
test a distributed application on a single computer with any of
the supported communications drivers. You can test the application
in a single process or run separate processes for the client and
server components.

NamedPipes driver

To test locally with the NamedPipes driver, you need a Windows NT machine. Server
support is not provided for this driver on other platforms.

Example

The following script establishes a client connection to a
server application that is available locally. This example uses
the WinSock driver. To tell PowerBuilder to service requests locally,
the client sets the Location property to Localhost:

For this example to work, the TCP/IP hosts file on
the test machine would need to include an entry for localhost:

In addition, the TCP/IP services file on the test
machine would need to include an entry for the myapp application
service:

Using the trace facility

PowerBuilder provides
several trace options to help you identify and fix problems that
may arise once an application is running in a distributed environment.
The trace options allow you to monitor client/server communications
by logging system activity to a console window or to a file.

The trace facility is available to both the client and server
components of a distributed PowerBuilder application. You can use
the trace facility to monitor system activity on either the client
or the server, or you can monitor activity on both the client and
the server simultaneously. The trace facility does not work with
Jaguar components.

Specifying trace options

To use the trace facility,
you need to assign a value to the Trace property of either the Connection
object on the client or the Transport object on the server.

Trace option keywords

The value you assign can specify one or more of the trace
option keywords:

Trace option Description
All=1 Logs all activity against the server.
This option logs internal information that can be helpful in debugging,
including memory usage, an internal call trace, and the types and
values for passed parameters
Console=1 Logs activity to a console window
DumpArgs=1 Logs parameter types and values
Level=1 Enables Console=1, ObjectCalls=1,
ObjectLife=1, and WebPB=1
Log=filename Logs activity to the specified file.
If the server application uses multiple Transport objects, you need
to specify a unique log file name for each Transport object
ObjectCalls=1 Logs each object method call and indicates
whether the call was successful
ObjectLife=1 Logs each attempt to create or destroy
a remote object and indicates whether the operation was successful
WebPB=1 Logs all Web.PB activity against the
server application (Transport object only)

If you specify more than one keyword, the keywords must be
separated by commas.

Examples

This example sets the trace option for the Transport object
on the server to log each attempt to create or destroy an object,
or call one of its methods. The output displays in a console window
on the server machine:

This example sets the trace option for the Transport object
to log each attempt to create or destroy an object. The output displays
in a console window on the server machine:

This example sets the trace option for the Connection object
to log each call to an object method. The output is logged to a
file on the client machine.

On Windows:

On UNIX:

Viewing the trace output

This section shows sample output for several of the trace
options.

Example 1: ObjectCalls=1

This example shows trace output you might see on a server
when the ObjectCalls=1 option is enabled. The log indicates
that a client connected to the server, created an instance of a
remote object, and called a function f_myfunc, which takes
a single argument:

Example 2: All=1

This example shows trace output you might see on the client
when the All=1 option is enabled. The log indicates that
the client made an asynchronous call to a function called f_double
that takes two arguments. The first argument is a long value that
specifies the number that the function will double. The second is
an object of type nvo_response_object. The object
reference provides the server with a way to push a response back
to the client. To send a message back to the client, the server
calls the notify_client function:

A collection of techniques you can use to implement general
features in the applications you develop with PowerBuilder. Includes
printing from an application, developing for multiple platforms,
and internationalizing an application.


Document get from Powerbuilder help
Thank you for watching.
Was this article helpful?
Subscribe
Notify of
guest
0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x