Back in the late 1980s I was using a data management tool known as DataEase. At the time it was a DOS-based tool that communicated only with its own proprietary database files. Essentially it was a competitor to dBase, but one that was more network-aware and provided better screen-generation capability.

This was the pre-Internet age, but if there was something like a TeamSybase for DataEase, I'm sure John Olson (also of TeamSybase and a former PBDJ editor) and I would have qualified. We were highly active in the DataEase forums on CompuServe and traveled to LA monthly to participate in the DataEase user group (we were both working for the same company in Santa Barbara at the time).

Then two major paradigm shifts hit. The first was the introduction of Windows 3.0 (and, more important, its significant acceptance as compared to the lukewarm reception that Windows 1.0 and 2.0 received). The second was the growing popularity of client/server relational databases (Oracle, Sybase, MS SQL Server, etc.). DataEase attempted to respond to both of those through new major versions. The first new major version would open up access to client/server relational databases; the second would add a Windows-style GUI interface rather that DOS character-based screens.

We were planning on moving to Oracle in order to provide a centralized database for our various applications and were also moving toward Windows, so we were highly interested in the new versions. As a result, we joined the beta and started building prototypes of our new Oracle-based centralized database applications using the beta. Everything went swimmingly until just after the last beta build and before the GA release. When we installed the GA, all of the prototypes we had built started experiencing tremendous performance problems.

As it turned out, during the beta the SQL Server users were having problems with some of their queries. DataEase tweaked the GA release to correct this, but in the process modified the behavior of the Oracle interface so that it was forced it to do all joins client-side. That is, the minute there was a join in a query, the client would retrieve all of the records in all of the tables involved in the query and then attempt to join them on the client. Needless to say, performance was unacceptable as a result.

That's when we started our search for a new database application development tool, one that was more intelligent with regard to working with a client/server database and one that supported Windows-style GUI interfaces. Fortunately for us, PowerBuilder 1.0 had just been released and, after a head-to-head evaluation against Gupta SQL Windows (the other tool we were considering), we adopted PowerBuilder as our new development tool. The rest, as they say, is history.

Why "déjà vu all over again"? The problem with DataEase is that they were a superior product for the existing infrastructure, but one that did not adapt well enough or quickly enough to infrastructure changes. Our own need to adapt to those changes eventually required us to abandon that product and adopt a new one. We've seen additional infrastructure changes lately, the first being the Internet and, more recently, the introduction of Java and .NET as new "platforms." PowerBuilder was a superior product for client/server development on standard Windows, but the question is whether it can adapt fast enough to meet developers' needs in an Internet and Java/.NET world. Many developers have already said "no" and have moved on.

Recently, Sybase has begun work on their own new major versions in an attempt to address those changes. The first (10.5, which we will cover in the February issue) is one that attempts to address (among other things) long-standing deficiencies in their GUI and Web services support. The second (11.0) is one that provides better support for .NET. They've also begun work on a plug-in for third-party Java application servers (PASP, which we will cover in the April issue) that would allow PowerBuilder to play more fully in the Java space.

How well they implement those new versions will determine if Sybase can pull it off. One problem is that they have positioned themselves as a services company, not a products company. In order for PowerBuilder to succeed, they need to remember who their customers for PowerBuilder are. Meet the needs of those developers and they'll stick with you through thick and thin. Fail to meet their needs, and they'll have no choice but to move on.