Novalys, your PowerBuilder Specialist


Migration Information

You can migrate a PowerBuilder application from any version of PowerBuilder directly to PowerBuilder Classic. You cannot migrate applications from PowerBuilder .NET to PowerBuilder Classic, or from PowerBuilder Classic to older versions of PowerBuilder.
Migrate older applications to PowerBuilder Classic before you port them to PowerBuilder .NET.

Migration to PowerBuilder .NET

The WPF Window Application wizard in PowerBuilder .NET provides an option for converting a standard PowerBuilder Classic client/server or a Windows Forms target to a WPF Window Application target. The .NET Assembly wizard in PowerBuilder .NET provides an option to convert a PowerBuilder Classic .NET Assembly target.

After you select these conversion options and click Finish, the wizards automatically migrate the PowerBuilder Classic targets you select. However, you may still need to manually refactor some applications after you convert them.

This table lists some of the features that require special attention after you migrate applications from PowerBuilder Classic. Topic references in the table are to the PowerBuilder .NET Features Guide.

Feature Effect of Migration
Accelerator characters Ampersand (&) changed to underscore (_). See Accelerator Characters in Control Labels.
Conditionalized (preprocessor) code blocks Invalid code blocks for PowerBuilder .NET are maintained, but ignored. See Conditional Compilation in PowerBuilder .NET Targets.
Control handles Controls nested in windows do not have their own handles. See Modified and Unsupported Features in PowerBuilder .NET .
Dashes in identifiers Dashes are replaced with a string you can select in the target wizard. See Coding Restrictions.
Event sequence May require manual refactoring. See Modified and Unsupported Features in PowerBuilder .NET .
GroupBox controls Controls that are inside a GroupBox belong to the GroupBox, not to the container of the GroupBox. SeeSemantic Differences.
Large application migration May cause OutOfMemory error. Turn on 3G switch to avoid this error. See Memory Tuning for Large Applications.
Menu and toolbar styles Maintained from PowerBuilder Classic. If you migrate PowerBuilder applications earlier than 11.0, menus and toolbars use traditional styles. See Selecting a Toolbar Styleand Menu Styles in PowerBuilder .NET.
Non-TrueType fonts Visible at design time, but replaced at runtime. See Modified and Unsupported Features in PowerBuilder .NET .
Pipeline and Query objects Imported, but ignored at runtime. See Modified and Unsupported Features in PowerBuilder .NET .
Resource files Resource directories that you select in the wizard are copied relative to the new target path, based on the relative path to the original target. See Adding Resources to a Target andProject Painter User Interface.
Skins Default skins are attributed to migrated applications. SeeSkin Selection for Applications and Controls,

The WPF application includes migration options for applications with dashes in identifiers and with right-to-left formatting. If you click Finish before making a migration option selection, the wizard migrates the application using default settings for these options.

Migration to PowerBuilder Classic

You can migrate applications from any earlier version of PowerBuilder to PowerBuilder Classic 12.6.

Before you migrate, back up your files and use the Migration Assistant to identify obsolete code. The applications you build using the current version of PowerBuilder must be deployed with the PowerBuilder runtime DLLs from the current version.

Note

The "Migrating PowerBuilder Applications" technical document at http://wiki.scn.sap.com/wiki/display/SYBPB/Migrating+PowerBuilder+Applications published on SAP site includes information on changes to PowerBuilder since version 6.5 that might affect the conversion of applications to a more recent PowerBuilder version.

In this section:

When you migrate .NET Web Service components, you might need to remove or install supporting files on development and deployment computers.

If you deployed .NET projects from earlier versions of PowerBuilder, verify or complete these steps before redeploying the migrated .NET projects:

  • For .NET Windows Forms projects, select Full for the project rebuild type before you redeploy your applications from PowerBuilder Classic for the first time.
  • For .NET Web Service targets, clear ASP.NET temporary files for the application or component on development computers and production servers.
    The temporary files are located in the C:\WINDOWS\Microsoft.NET\Framework\<version>\Temporary ASP.NET Files\<projectName> directory, where <version> is typically v2.0.50727, and <projectName> is the project’s Web application name or its Web service virtual directory name.
  • For all .NET targets, uninstall earlier versions of PowerBuilder runtime files (system assemblies and win32 DLLs) on all deployment computers or servers, then install the runtime files for the current version of PowerBuilder using the Runtime Packager or another tool, as described in the “Checklist for deployment” section of the Deploying Applications and Components to .NET book.
  • To migrate a PowerBuilder 12.0 or 12.1 solution, open its .PBWX file using the File menu. If you double-click or drag and drop the file into PowerBuilder .NET 12.6, the Visual Studio Conversion wizard opens, inappropriately. You can use the double-click and drag-and-drop methods to open PowerBuilder 12.6 solutions.

 

Note
You can convert .NET Windows Forms targets to WPF targets in PowerBuilder .NET. SAP suggests that you migrate older .NET Windows Forms targets to PowerBuilder Classic before you convert them to WPF targets. You cannot directly convert .NET Assembly targets in PowerBuilder Classic to .NET Assembly targets in PowerBuilder .NET.

Migrating EAServer targets from earlier versions of PowerBuilder to PowerBuilder Classic may require some additional considerations. PowerBuilder .NET does not support EAServer targets.

Migrating Components to EAServer 6.0.1 or Later

Intercomponent calls from a PowerBuilder component running in EAServer 6.0.1 require proxies for all called components. In earlier versions of EAServer, a PowerBuilder component can sometimes call another PowerBuilder component running in the same server without the use of a proxy, because the PowerBuilder VM dynamically creates a proxy for the component using method names that match the names of the component's methods.

In EAServer 6.0.1 and later, PowerBuilder components are wrapped as EJBs, providing an extra layer of security and preventing the PowerBuilder VM from dynamically generating a proxy with names that match the component's method names. Therefore, you must create a proxy object for all components you invoke with intercomponent calls. Without a proxy object, the TransactionServer object cannot obtain the correct method names of the component you are calling.

Accessing EAServer Components from .NET Targets

PowerBuilder installs the EAServer DLLs, com.sybase.iiop.net.dll and com.sybase.ejb.net.dll, in the Global Assembly Cache (GAC) on the development computer, and requires these DLLs on runtime computers for applications that access EAServer components from .NET targets. You can use the Runtime Packager to place these DLLs in the GAC on deployment computers.

Note
The DLLs intalled by the PowerBuilder setup program have been tested, and are compatible with EAServer 6.3.1. However, if you use an EAServer version other than 6.3.1, SAP recommends that you copy the DLLs from the EAServer/Lib directory to the GAC of all computers where you deploy your applications. If you then run or re-run the Runtime Packager, you must also recopy these DLLs to the GAC, because the Runtime Packager overwrites them.

Creating an EJB Client Proxy for an EAServer 6.x Component

Building EJB client applications for EJBs running in EAServer 6.x requires additional steps when you create the EJB client proxy.

Procedure

  1. Copy the <packagename> directory from the %DJC_HOME%\deploy\ejbjars\ directory on the server to the client computer, where <packagename> is the package that contains the EJB you want to use.
  2. In the Select EJB Component dialog box that you open from the EJB Client Proxy project painter, add this directory to the class path.
  3. Generate the proxy.

Creating a Client Application for an EAServer 6.x EJB Component

Building EJB client applications for EJBs running in EAServer 6.x requires additional steps when you create the client.

Procedure

  1. Copy the eas-server-15.jar file (or eas-server-16.jar if you are using JDK 1.6.x) from the %DJC_HOME%\lib directory to the client computer and include its full path in the client’s CLASSPATH.
  2. Copy the stub files from %DJC_HOME%\genfiles\java\classes\ directory to the client computer and include this path in the client’s CLASSPATH. Copy the <packagename> directory from the %DJC_HOME%\deploy\ejbjars\ directory on the server to the client computer, where <packagename> is the package that contains the EJB you want to use, and include this path in the client’s CLASSPATH.
    If you copied these files and directories to a directory on the client called EAServer6, and you want to use an EJB in a package named datamapping, the client CLASSPATH setting might look like this:
    Classpath=D:\EAServer6\lib\eas-server-15.jar;D:\EAServer6\genfiles\java\classes;D:\EAServer6\deploy\ejbjars\datamapping

In PowerBuilder versions 10.5 and later, you cannot use system types as variable names in Web service proxies.

If a PowerBuilder system type is used as a variable name, the Web Service Proxy wizard renames the variable by applying the prefix ws_. If you are migrating Web service applications from PowerBuilder 10.2 or earlier, and regenerating the Web service proxies in PowerBuilder 10.5 or later, you may need to modify your code to reflect the change in variable names.

PowerBuilder system types include not only the objects and controls listed on the System tab page in the PowerBuilder Browser, but also the enumerated types listed on the Enumerated page in the Browser, such as band, button, encoding, location, and weekday. For example, if you build a Web service from a PowerBuilder custom class user object, and one of its functions has a string argument named <location>, in the proxy generated for that Web service, the argument is changed to <ws_location>.

In PowerBuilder 10.5.2 and later, when you use the OLE DB database interface with a Microsoft SQL Server database and retrieve data into a DataWindow, or use an embedded SQL cursor in a SELECT statement, server-side cursors help to support multiple command execution.

If this has a negative impact on performance, try increasing the size of the Block database parameter to 500 or more, or adding the following line to the [Microsoft SQL Server] section in the PBODB initialization file to turn off server-side cursors:

 ServerCursor = 'NO'
      

A change was made in PowerBuilder 10.2.1 Build 9716, PowerBuilder 10.5.1 Build 6505, and PowerBuilder 11.0 Build 5021, to correct an anomalous behavior when the SelectedTab property was applied at runtime to a tab for which the Visible property was set to false.

As a result of this change, there is a change in the behavior of the OpenTab and OpenTabWithParm functions. In earlier versions, calling the OpenTab or OpenTabWithParm function to open a user object as a tab page displayed the tab page even if the user object’s Visible property was set to false. In the current version, the user object’s Visible property must be set to true for the tab page to appear.

If your application uses the ImportFile method to import very large text files into a DataWindow or DataStore, ImportFile returns the error code -15.

PowerBuilder versions 10.0 and later are Unicode enabled. Earlier ANSI versions of PowerBuilder were able to import larger text files

Note
The release bulletins for earlier versions listed the size limit for large files as approximately 839,000 lines. However, the size limit depends on the number of columns in the files, as well as the number of lines.