PowerBuilder 11.0 supports deploying existing PowerBuilder client/server business applications as an ASP.NET WebForm application. This greatly improves developer productivity without having to learn a new development language and preserves PowerBuilder development skills. Although the deployed WebForm application retains all the functionality of its original client/server application, due to the technological shift in the running environment from a two-tier client/server environment to a three-tier Web paradigm, some features of PowerScript will not be supported in a Web environment. And due to language restrictions between .NET and PowerScript, you may need to rework/refactor your code to make it suitable for .NET development.

This article will walk through some of the coding techniques recommended when converting an existing client/server application to an ASP.NET WebForm application or developing new applications for ASP.NET WebForm deployment from PowerBuilder 11.0. I categorize the recommendations below as sub-topics

• Language restrictions between PowerScript to .NET
• Unsupported features in a Web environment
• Recommended coding practices
• Global configuration properties

Language Restrictions
Compared to PowerScript, .NET languages (i.e., C#) are syntactically stricter than PowerScript. As a result, the PowerScript code that compiles successfully in a PB Win32 (PB native) implementation may throw a compilation error from the PowerBuilder .NET compiler when deploying a client/server application to an ASP.NET WebForm application.

It's better to know these language differences in advance and correct them in the PB code prior to deployment. The following are some of the syntax and semantic issues between PowerScript and C# languages.

Syntax Issues
GoTo Statement
In PowerScript local scripts (script in the event or function body), there is no concept of scope in a single block of script. Let's look at an example:

If  withdraw_amount > 2000 then
....
surcharge:  //label begin here
calculate_surcharge()
....
....
//end of label

Else
....
End if
....
....
goto surcharge

In this PowerScript code, whenever it encounters the goto statement, it transfers control back to the label "surcharge" even though the label is declared inside the if statement. The PowerScript compiler successfully compiles this piece of code and executes it.

However, if you try to deploy this application as an ASP.NET WebForm, this code conceptually gets translated into the following C# code:

if (withdraw_amount > 2000)
{
surcharge:  //opening a new scope
calculate_surcharge();
...
//surcharge scope ends here
}
else
{

}
....
....
goto surcharge;

In C# the GoTo statement is not allowed to jump to a label to a different scope and the translated code results in a compilation error.

Hence when you intend to deploy a PB application to an ASP.NET WebForm application, avoid using a GoTo statement in the PowerScript code. It is recommended that you totally avoid GoTo statements even if the applications are not compiled as ASP.NET Web applications. Local functions (Window or User Object functions) are an alternative to labels and instead of using GoTo, you can call these functions.