PowerScript

PowerScript is the programming language of PowerBuilder, the client/server application development tool that Powersoft Corporation of Burlington, Massachusetts released in July 1991. It is an object-oriented, event-driven language: a PowerBuilder application is a set of objects - windows, the controls on them, menus, user objects and non-visual “NVO” classes - and PowerScript is what one writes in the scripts attached to their events and functions. Its statement syntax is BASIC-like (IF ... THEN ... END IF, FOR ... NEXT, DO ... LOOP, CHOOSE CASE, & to continue a line), SQL is embedded directly in the code with host variables, and the heavy lifting of retrieving, displaying and updating database rows is done by the DataWindow, the data-bound control that made PowerBuilder famous and that PowerScript exists largely to drive.

The language was never sold on its own. It came with PowerBuilder, and it followed the product through four owners: Powersoft, which was bought by Sybase in a merger completed in February 1995; Sybase, bought by SAP in 2010; and, since a licence agreement of July 2016, Appeon, which has released a new PowerBuilder every year or so and shipped PowerBuilder 2025 R2 on 3 June 2026. That history is the reason to be careful with the word “dormant” that catalogues attach to PowerScript. Its market position has shrunk since the 1990s, when PowerBuilder was the leading client/server tool, and it has been in the TIOBE index’s alphabetical 51-100 band for years; but the language is maintained, extended (JSON, REST, HTTP and cryptography functions were all added between 2018 and 2021) and in production in thousands of organisations, most of which would rather not be reminded of the fact.

History and Origins

Powersoft and “Headstart”

Mitchell Kertzman started Computer Solutions Inc. in 1974 as a one-person contract programming business; by the 1980s it sold GrowthPower, a manufacturing (MRP II) package for the HP 3000 minicomputer. In 1988 Kertzman hired David Litwack, formerly executive vice president of product development at Cullinet, to build a graphical client/server development tool for the new Microsoft Windows, and in 1990 the company renamed itself Powersoft. The tool went into beta in August 1990 under the code name “Headstart” and shipped as PowerBuilder 1.0 in July 1991, for Windows 3.x, at a time when “client/server” meant a PC front end talking to a SQL database on a departmental server. Trade accounts say it sold about $5.2 million in its first six months, and PowerBuilder 2.0 followed within a year.

Two things distinguished it. The first was the DataWindow, a control that encapsulated a SQL query, its presentation (grid, free-form, tabular, graph, later HTML and PDF) and the SQL needed to write changes back, and that could be designed in a painter without code. The second was PowerScript, which was designed around the events of the Windows programming model rather than around a main program: the developer selected an object, selected an event such as Clicked or Open, and wrote the script for it. The combination let a corporate developer who had never seen the Windows API build a forms-over-data application in days, and it is the reason PowerBuilder is generally credited, with Visual Basic (also 1991) and Gupta’s SQLWindows, with defining the rapid-application-development category.

The Powersoft years

Powersoft went public on 3 February 1993 and used its stock to buy Watcom International of Waterloo, Ontario, in a deal announced in late 1993; Watcom’s small SQL database was bundled with PowerBuilder 3.0 (May 1993) as a single-user development database and lives on today as SAP SQL Anywhere. PowerBuilder 4.0 (1994) added OLE 2.0 support and the Data Pipeline for moving data between databases. By then the tool was, in the contemporary description, the leading client/server development tool, and on 15 November 1994 Sybase - the database company whose SQL Server it most often talked to - announced a stock-swap merger valued at about $940 million. It closed in mid-February 1995 at roughly $904 million after Sybase’s shares fell, and Kertzman became Sybase’s chief executive. A Tech Monitor piece of November 1996 called the arrangement the tail wagging the dog: Powersoft’s tools were a quarter or more of the combined company’s revenue, and Litwack’s line was “They will own the product - that’s Mitch’s goal”.

PowerBuilder 5.0, in the spring of 1996, was the high point of the Powersoft era and the release that most changed the language’s execution model. Until then PowerScript was compiled to p-code and interpreted by the PowerBuilder runtime; 5.0 added an optional compiler to native machine code. A Government Computer News review of 27 May 1996 reported that in its tests a machine-code PowerBuilder application ran “just about as fast as an application written and compiled in C” - a reviewer’s impression on the hardware of the day rather than a benchmark, but a fair summary of why the option existed. The same release shipped the PowerBuilder Foundation Class library (PFC), a large set of ancestor objects and services for building applications by inheritance, Distributed PowerBuilder for three-tier designs, and support for ActiveX/OCX controls. Editions for DEC Alpha NT, Macintosh and Unix were promised for late 1996, and by version 6.5 (1998) PowerBuilder was sold in separate Unix, Macintosh and Unicode editions; those non-Windows editions did not survive the decade.

Sybase, the web, and .NET

Sybase’s PowerBuilder 7.0 (1999) had a redesigned IDE and targeted the company’s Jaguar/EAServer application server, and 8.0 (2001) introduced the workspace-and-target project model that survives today, “Web targets”, and - the biggest change to PowerScript since 1991 - structured exception handling with TRY, CATCH, FINALLY, THROW and a hierarchy of Throwable classes. PowerBuilder 9.0 (early 2003) added the PowerBuilder Native Interface (PBNI), a C++ SDK for writing visual and non-visual extensions and for embedding the PowerBuilder virtual machine in other programs, along with XML DataWindows and PDF output; 10.0 (July 2004) made PowerScript and its String datatype fully Unicode.

From 2004 the story is a decade-long attempt to carry PowerScript onto .NET. PowerBuilder 11.0 (July 2007) deployed non-visual objects as .NET assemblies and whole applications as Windows Forms or ASP.NET Web Forms; 12.0 (April 2010) added a second IDE, PowerBuilder .NET, hosted in the Visual Studio isolated shell, that compiled PowerScript to WPF applications. In the middle of that, SAP announced on 12 May 2010 that it would buy Sybase for about $5.8 billion, completing the deal in late July; the 12.5 release of 12 September 2011, announced at Sybase’s TechWave conference, was billed as the product’s twentieth-anniversary release and added WCF services and a REST client to the .NET side. Adoption of PowerBuilder .NET was poor, and SAP’s attention was elsewhere. A “PowerBuilder 15” beta announced at TechEd Bangalore in December 2013 finally shipped in August 2014 renumbered as PowerBuilder 12.6, with OData support, 64-bit compilation of classic Win32 applications and dockable IDE windows. It was SAP’s last release, and for two years the community’s assumption was that it would be the last of all.

Appeon

Appeon, founded in 1999 and long a Sybase partner, had since 2003 sold Appeon Web, a product that deployed existing PowerBuilder applications as .NET web applications, and later Appeon Mobile for iOS and Android. On 5 July 2016 it announced an agreement with SAP under which Appeon would “develop, sell and support its own offering powered by PowerBuilder technology”, with SAP retaining the intellectual property; its chief executive Armeen Mazda said the company was “now in a position to do much more than before”. PowerBuilder 2017 shipped on 30 June 2017. It dropped the PowerBuilder .NET IDE and WPF targets (“discontinued since 2017”, the upgrade guide says, for lack of demand), kept the classic Win32/Win64 product, and moved to subscription licensing.

The Appeon releases since then have changed the language more than SAP’s did. 2017 R2 (January 2018) added Git and Subversion integration and, to PowerScript itself, HTTPClient, RESTClient, JSONParser and JSONGenerator objects; 2017 R3 (July 2018) added cryptography functions and OAuth 2.0. PowerBuilder 2019 (31 May 2019) introduced a parallel C# toolchain - the SnapDevelop IDE and an open-source .NET DataStore that reproduces the DataWindow’s data-handling on the server - and 2019 R2 (3 April 2020) shipped the PowerScript Migrator, a converter that Appeon says moves 80-95% of non-visual PowerScript and embedded SQL to C# one function or event at a time. 2019 R3 (January 2021) split the runtime from the IDE and was the first long-term-support release in the modern sense; 2021 rebuilt PowerServer, the successor to Appeon Web, on .NET Core; 2022 (September 2022) ran 64-bit applications in the IDE and added TLS 1.3 and HTTP/2; 2022 R3 (8 January 2024) is the current LTS release. PowerBuilder 2025 (7 May 2025) replaced the code editor and the compiler and introduced a plain-text “Solution” format friendlier to version control; 2025 R2 (3 June 2026) added dark mode, .NET 10 support and exploit-mitigation flags (ASLR, DEP, SafeSEH, CFG) on generated executables. The roadmap for 2025 R3 lists Claude AI code completion and an AI assistant in the IDE, and an ARM runtime for Windows on ARM devices.

Design Philosophy

Scripts, not programs

The organising idea of PowerScript is that code belongs to objects and runs in response to events. There is no main; an application object has an Open event, whose script typically opens the first window, and everything else happens because a user clicked, typed, tabbed, dragged or closed something, or because a script asked another object to run one of its events or functions. Every object type comes with system events (Clicked, Constructor, Destructor, Open, Close, ItemChanged, RetrieveEnd and about 150 others), each either mapped to a Windows message and supplied with arguments by the runtime, or raised by PowerBuilder itself. Developers add user events, with or without a message mapping, and declare their argument lists and return types in a dialog; an event can be triggered (run now, return value available) or posted (queued behind the current script, return value lost), which is the language’s principal concurrency idiom.

A consequence is that a PowerScript “program” is not a text file. Objects are designed in painters and stored in PowerBuilder Library (.pbl) files, and source is exported as .srw, .sru, .srd and similar files whose forward ... end forward, global type ... end type and type variables ... end variables sections are generated by the tool. Since PowerBuilder 2025 a Solution can store this source as plain text for Git, which Appeon rightly counts as a major change.

Objects and inheritance

PowerScript has had single inheritance, encapsulation and polymorphism since PowerBuilder 2.0, and the object model is simple and rigid in the way that suited its audience. Every class descends from PowerObject; visual classes (Window, UserObject, the controls) and non-visual classes (NonVisualObject, Transaction, DataStore) form two trees. A descendant window inherits its ancestor’s controls, instance variables, functions and event scripts, and a descendant event script runs after the ancestor’s unless the developer overrides it. Three pronouns anchor the model: This is the object that owns the script, Parent is the object that contains it (a control’s window, a menu item’s menu) and Super calls the immediate ancestor’s version of a function or event (Super::EVENT Clicked()). Instance variables and functions carry access modifiers - public, protected, private, plus the PowerScript-specific privateread, privatewrite, protectedread and protectedwrite, which split read and write access - and functions may be overloaded by argument list. Calls can be made statically or, with the DYNAMIC keyword, resolved at run time against whatever the object turns out to be.

The PFC library, which shipped with 5.0 and has been open source under the MIT licence for years (the OpenSourcePFCLibraries organisation on GitHub updated its PowerBuilder 2025 editions in June 2026), is the canonical expression of this style: applications inherit from PFC ancestors and enable “services” - resize, sort, filter, row management, error handling - that are themselves NVOs attached to the DataWindow.

The DataWindow and embedded SQL

PowerScript’s relationship with the database runs at two levels. At the low level the language has SQL statements of its own: CONNECT, DISCONNECT, COMMIT, ROLLBACK, SELECT ... INTO :variable, INSERT, UPDATE, DELETE, cursor DECLARE/OPEN/FETCH/CLOSE, stored-procedure calls and four formats of dynamic SQL, all executed through a transaction object (by default the global SQLCA) whose SQLCode and SQLErrText properties carry the result. Host variables are prefixed with a colon, and the statements are terminated with semicolons where ordinary PowerScript statements are not.

At the high level the developer rarely writes any of that. A DataWindow object holds the query, the presentation and the update rules; a script calls dw_1.Retrieve(args), lets the user edit, calls dw_1.Update() and commits. The DataWindow validates input, tracks the row status (new, modified, deleted), generates the appropriate INSERT, UPDATE and DELETE statements for the connected DBMS, and raises events (ItemChanged, ItemError, UpdateStart, SQLPreview) that PowerScript can hook. DataStore, its non-visual twin, gives the same buffer without a screen, and is what Appeon’s .NET DataStore reproduces in C#. That division of labour - imperative PowerScript around a declarative data object - is the design; it is why PowerBuilder programs are short, and why they are hard to migrate to anything that lacks an equivalent.

Pragmatic typing

PowerScript is statically typed, with the standard datatypes one would expect of 1991 plus a few that show their age: Integer is 16-bit and Long 32-bit, with LongLong (64-bit) and Byte added later, Real is single precision and Double double, Decimal carries up to 28 digits for money, Char, String (up to about a billion Unicode characters), Boolean, Blob, Date, Time and DateTime, and Longptr, which is 4 bytes in a 32-bit build and 8 in a 64-bit one for passing handles to the Windows API. Numeric types promote in expressions; there are enumerated types (Alignment, Button!-style values end in an exclamation mark, as in MessageBox("Title", "Text", StopSign!, OKCancel!)), user-defined structures, and arrays with fixed or variable bounds. The Any datatype accepts a value of any type for generic code. NULL is a first-class state of every variable: SetNull() sets it, IsNull() tests it, most functions return NULL when given NULL, and a NULL boolean expression is treated as false, which is a rule PowerBuilder developers learn early and the hard way.

The Language

A window script

The script for the Clicked event of a command button cb_save on a window that holds a DataWindow control dw_customer. Statements end at the line; & continues one; comments are // or /* */, and the latter nest:

// Clicked event of cb_save
integer li_rc

li_rc = dw_customer.AcceptText()   // push the pending edit into the buffer
IF li_rc <> 1 THEN RETURN

IF dw_customer.Update() = 1 THEN
    COMMIT USING SQLCA;
    MessageBox("Saved", String(dw_customer.RowCount()) + &
               " customer rows written")
ELSE
    ROLLBACK USING SQLCA;
    MessageBox("Update failed", SQLCA.SQLErrText, StopSign!)
END IF

Embedded SQL

The same work without a DataWindow, showing host variables, the transaction object and the SQL statement terminator:

string ls_name
long   ll_id = 42

SELECT cust_name INTO :ls_name
  FROM customer
 WHERE cust_id = :ll_id
 USING SQLCA;

CHOOSE CASE SQLCA.SQLCode
    CASE 0
        st_name.Text = ls_name
    CASE 100
        st_name.Text = "(no such customer)"
    CASE ELSE
        MessageBox("Database error", SQLCA.SQLErrText)
END CHOOSE

A non-visual object

Objects are built in painters, but their exported source is readable. A tiny NVO n_tax, marked autoinstantiate so that declaring a variable of the type creates an instance, as exported to an .sru file (comments added):

forward
global type n_tax from nonvisualobject
end type
end forward

global type n_tax from nonvisualobject autoinstantiate
end type

type variables
private decimal idc_rate = 0.0825
end variables

forward prototypes
public function decimal of_compute (decimal adc_amount)
public subroutine of_setrate (decimal adc_rate)
end prototypes

public function decimal of_compute (decimal adc_amount);
RETURN adc_amount * idc_rate
end function

public subroutine of_setrate (decimal adc_rate);
IF adc_rate >= 0 THEN idc_rate = adc_rate
end subroutine

Using it, with exception handling as introduced in PowerBuilder 8:

n_tax   lnv_tax        // created automatically: autoinstantiate
decimal ldc_total

TRY
    ldc_total = Dec(sle_amount.Text) + lnv_tax.of_compute(Dec(sle_amount.Text))
    sle_total.Text = String(ldc_total, "$#,##0.00")
CATCH (RuntimeError lre)
    MessageBox("Error", lre.GetMessage())
FINALLY
    sle_amount.SetFocus()
END TRY

The prefixes - w_ window, dw_ DataWindow control, cb_ command button, n_ NVO, li_/ll_/ls_/ldc_ local integer, long, string and decimal, ii_/is_ instance variables, a arguments, of_ object functions, ue_ user events - are not part of the language but are the Powersoft and PFC naming conventions, and nearly every PowerBuilder shop uses some version of them.

Events, triggering and posting

// Declared on the window: user event ue_refresh (no event ID, no arguments)
This.EVENT ue_refresh()            // trigger: runs now
This.POST EVENT ue_refresh()       // post: runs after the current script
dw_1.TriggerEvent("ue_refresh")    // by name, resolved at run time
lo_anything.DYNAMIC of_describe()  // dynamic call on whatever lo_anything is

// A timer: the window's Timer event fires every two seconds
Timer(2)

Conditional compilation and platform code

PowerScript has #IF DEFINED ... #ELSEIF ... #ELSE ... #END IF with the predefined symbols PBNATIVE, PBWEBSERVICE and DEBUG, which is how one script can serve a desktop build and a web-service build. External functions - Windows API or any DLL - are declared once and then called like PowerScript functions:

FUNCTION ulong GetTickCount() LIBRARY "kernel32.dll"
FUNCTION boolean SetWindowTextW(longptr hwnd, string text) LIBRARY "user32.dll"

Execution and Tooling

PowerScript is compiled inside the IDE into p-code stored with each object, and an application is deployed either as a single executable with embedded p-code, or as an executable plus .pbd dynamic libraries, together with the PowerBuilder runtime DLLs (the virtual machine, pbvm, and database interface DLLs). Since 5.0 the alternative has been machine-code generation, which produces C-compiled DLLs and was aimed at compute-heavy scripts; the documentation has always described the benefit as situational. Since 12.6 executables can be 64-bit, since 2019 R3 the runtime is versioned separately from the IDE, and since 2022 64-bit applications can be run and debugged inside the IDE, which itself remains a 32-bit program (a 64-bit IDE is on Appeon’s future roadmap). The product runs on Windows only; the Unix and Macintosh editions of the late 1990s are long gone, and the 12.6 release bulletin’s supported list ran from Windows XP SP3 to Windows 8.1.

PowerServer - the descendant of Appeon Web - takes a PowerScript application, converts the client to a thin installable and the DataWindows and business logic to .NET services, and hosts it on IIS or in the cloud; PowerClient does the installable part alone. The C# side (SnapDevelop, .NET DataStore, SnapObjects, the PowerScript Migrator) is Appeon’s answer to the question the .NET-era Sybase releases never settled: how to get out of PowerScript gracefully. The migrator’s own documentation says it is meant for one function or event at a time, not bulk conversion, and that the C# it produces depends only on open-source libraries.

Current Relevance

PowerScript is a maintained commercial language with a small, unusually loyal base. Appeon’s own figures - more than 18,000 organisations, “most” of the Fortune 500, 700-plus customers with teams of 15 to 300 PowerBuilder developers - are vendor claims and cannot be checked, but the customer list it publishes (AT&T, Accenture, CBIZ, CTS Eventim, PEMEX, public bodies such as the provincial council of Almería) and the volume of migration-services advertising aimed at PowerBuilder shops both testify to a large stock of production code in banking, insurance, government, health care, utilities and higher education. The pattern is the one familiar from COBOL: the applications were written in the 1990s, they still work, and the cost of rewriting them is the reason the tool survives.

The community infrastructure is correspondingly modest and steady: Appeon’s Community site and Q&A, the annual Elevate conference (first held in September 2017, online since 2020 and now spread through the year), national user groups such as the German PowerBuilder User Group, PowerBuilder.TV webinars, the PFC libraries on GitHub, and a handful of veteran bloggers - Chris Pollach and Bruce Armstrong among them - who have documented every release since the Powersoft era. TIOBE has tracked PowerScript for two decades and placed it in the 51-100 band in August 2026. Appeon’s cadence is a feature release every ten to twelve months with an LTS release roughly every two years; 2017 R3 reached end of life on 31 July 2025, 2022 R3 is the current LTS, and 2025 R3 is in development.

Why It Matters

PowerScript matters for two reasons that are almost opposites. The first is that PowerBuilder, in 1991, showed what a language designed around a data-bound control could do: a developer wrote a few dozen lines of event scripts, the DataWindow generated the SQL, and a working multi-window database application came out the other end. Visual Basic had the events and Gupta had the SQL, but PowerBuilder had both plus the DataWindow, and for the middle of the 1990s it was the tool corporate IT chose; the merger that made it the centrepiece of Sybase’s strategy was, at $904 million, one of the largest software acquisitions of its time. Every later “forms over data” framework, from Delphi’s data-aware controls to the ORMs and grid components of the web era, is solving the problem PowerBuilder solved first.

The second reason is what happened afterwards. PowerScript is the clearest example of a proprietary, tool-bound language surviving its vendor’s loss of interest: three owners in twenty years, a decade of .NET strategies that its users declined to follow, a version 15 that shipped as 12.6, and then a small partner taking over the product and doing what the large ones had not - adding Git, JSON, REST and TLS to the language, and building a path to C# that does not require abandoning the DataWindow. The catalogues that file it as dormant are describing its reputation; the release notes describe something else.