Related Topics: Java EE Journal, Java Developer Magazine

J2EE Journal: Article

Resolving PSR Compatibility Issues

Resolving PSR Compatibility Issues

The current PSR compatibility issues between PowerBuilder and the PowerJ Java DataWindow can be resolved using PowerScript and Java source to pass a DataWindow object's FullState, bringing your PowerBuilder reporting applications into the Java realm.

A Powersoft Report (PSR) is a data file that represents a snapshot of a DataWindow or DataStore, including data and presentation information. This mechanism allows the PowerJ or PowerBuilder developer to save the current state of a DataWindow or DataStore for reporting purposes. Through PowerBuilder and PowerJ a PSR can be viewed, printed, and manipulated; however, it can't make updates back to its data source. PSRs can be created within PowerBuilder, InfoMaker, DataWindow Builder, and Java DataWindow. Ideally, you can save a PSR in one of the products mentioned above and load it into another for viewing or printing at a later time. Currently, a conflict in storage formats prevents the use of PowerBuilder-generated PSRs within the Java DataWindow.

Introducing the Java DataWindow
The Java DataWindow is shipped with the PowerJ Java IDE. A 100% Java-implemented port of the PowerBuilder DataWindow control, it contains all the functionality of the original DataWindow with the exception of RichText, OLE, and Graph presentation styles. The DataStore, a nonvisual representation of the DataWindow, is also implemented within the Java DataWindow source code. It's a useful tool for Java development in nonvisual code such as Enterprise JavaBeans (EJBs). There are two versions of the Java DataWindow to support both AWT and Swing client-side architectures. With the introduction of the Java DataWindow, it's possible to bring DataWindow objects and PSRs to Java applets, applications, servlets, EJBs, and JavaServer Pages (JSPs).

Compatibility Issue
The PowerBuilder, InfoMaker, and DataWindow Builder codelines have changed with regard to PSR creation. Previously, PSRs were stored with an internal format that involved storage BLOBs. This storage format quickly exhausted memory when saving larger PSR reports. This overhead was resolved by introducing a standard OLE format save; however, the Java DataWindow wasn't designed to handle this format. When loading a PSR stored in the OLE storage format into the Java DataWindow, the following exception is seen in the Java console:

PBStorage Error: load: unable to load, file is in OLE storage format
DWObject Error: load: error loading PSR file c:\pbpsr.psr

The storage format change was made in the following PowerBuilder, Infomaker, and DataWindow Builder builds:

  • 6.5 build 1197
  • 7.0.2 build 8038
  • 8.0 build 1299
Enabling the Java DataWindow to load PSRs saved in the OLE storage format can be done only by calling OLE-related DLLs. The Java DataWindow is a 100% Java implementation and calling such DLLs would make it platform-dependent, not 100% Java implemented. Allowing the user to save a PSR with the original storage format is being considered in future builds of PowerBuilder, InfoMaker, and DataWindow Builder. This enhancement request has been sent to the PowerBuilder development staff under change request number 267522 and is expected no earlier than the PowerBuilder 9.0 codeline. The progress of this enhancement can be monitored by accessing clientID=172206&softpage=Solved_Cases using a search of "267522".

In the meantime, there's a workaround that will save a snapshot of your DataWindow or DataStore within PowerBuilder that can be loaded into the Java DataWindow and vice versa. The FullState property of the DataWindow object contains its entire state, including the DataWindow object specification, data buffers, and status flags. Using the GetFullState method of either the PowerBuilder or Java implementation stores the FullState into a BLOB or byte array. The FullState of a DataWindow object can then be written to a file using simple Java or PowerScript code. Although similar to creating a PSR, additional information (e.g., data buffers and status flags) is included.

Testing has shown that including this information in the FullState can result in data up to 10% bigger than a PSR. Although there's some overhead in this workaround, having access to the data buffers and status flags allows changes to be updated to the database. The ability to perform database updates is an advantage unavailable to PSR file use.

The following is the source to write out the current FullState of a PowerBuilder DataWindow or DataStore to a file in PowerScript:

integer iFileNum
Blob blob_data
iFileNum = FileOpen("c:\\mydwblob.bin", &
StreamMode!, Write!, LockWrite!, Replace!)
FileWrite(iFileNum, blob_data)

and to write out the current FullState of a Java DataWindow or DataStore to a file in Java:

try {
String _psrFile = "c:\\mydwblob.bin";
byte[][] b = new byte[1][];
dw_1.getFullState( b );
// b[0] contains the fullstate at this point fstream =
new _psrFile ); dataout =
new fstream );
dataout.write( b[0], 0 , b[0].length );
} catch ( Exception e ) {

The data file created in either sample can now be loaded into any PowerBuilder or Java process. The BLOB needs to be read from the data file and then added to the DataWindow object using the SetFullState method. Once the FullState has been applied to the DataWindow object, the data can be viewed, printed, and manipulated. Updates can also performed if the DataWindow object is pointing to the correct data source.

To read in the FullState of any DataWindow or DataStore from a file in PowerScript, use the following code:

integer iFileNum
Blob blob_data
iFileNum = FileOpen("c:\\mydwblob.bin", &
StreamMode!, Read!)
FileRead(iFileNum, blob_data)

Use the code in Listing 1 to read in the FullState of any DataWindow or DataStore from a file in PowerJ.

These code samples involve file I\O to save and load the FullState of a DataWindow. For security reasons the use of file I\O is restricted within normal applet scenarios. Necessary precautions must be taken when using this source within the context of an applet. This is commonly resolved by signing the applet for file I\O privileges.

An Application of the Workaround
Expanding on this idea, the DataStore object can be used within the context of a JSP to load a data file containing a DataWindow FullState. Once the FullState has been applied, methods to view or manipulate the DataStore can be invoked. A JSP is a Java architecture designed to create dynamic HTML responses based on Java source. The Java source (found between the <% %> braces in a JSP) is compiled by a J2EE-compliant application server each time the JSP is requested. Once the JSP is compiled, the application server returns the generated HTML back to the client. In the sample JSP (see Listing 2) the HTML equivalent of the DataWindow object's data and presentation (stored in the DataWindow.Data.HTML DataWindow object property) is output using the DataWindow's describe method. The Java DataWindow classes are stored in the DataWindow.jar file provided with PowerJ. A J2EE-enabled application server, such as the Sybase EAServer, requires the DataWindow.jar to be added to its Java classpaths before this JSP file can be compiled. Consult your application server's documentation for instructions on the proper deployment of JSPs.

Resolving this compatibility issue with the proposed workaround will allow you to share the responsibility of DataWindow reporting between PowerBuilder and the Java DataWindow provided with PowerJ. As J2EE Web applications take a stronger foothold in the technology marketplace, the ability to bring PowerBuilder-generated reports to J2EE Web applications is a powerful asset to the PowerBuilder developer interested in flirting with Java programming.

More Stories By Tim McConnell

Tim McConnell is a senior product support consultant for the enterprise solutions division of Sybase, Inc., in Waterloo, Ontario. He focuses primarily on the Sybase PowerJ and EAServer products.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.