SUMMARY OF COMPARISONS ON CLIENTS FOR CLIENT-SERVER (LONG)

From: Bill Coutinho <bill_at_tiete.dcc.unicamp.br>
Date: 25 Jun 1994 00:19:08 -0300
Message-ID: <2ug7nc$ji3_at_tiete.dcc.unicamp.br>


Hi.

2 weeks late, here is the summary of comparisons on many clients for SQL client-server. Please, e-mail comments to this summary to me. I'll send a second-round summary to all of you, but only 1 week late :-).

#####.... (70 x #) -> sections
-----.... (70 x -) -> mails

Enjoy.

######################################################################

Section 1 - Don't Forget


From: sayhow_at_solomon.technet.sg (Foo Say How)

You have missed out Objectiview! With Roche (sp?) depository and its tie in with ADW Case Tools it certainly offer better solution than the other platform.

With Visual Basic you have to rely on ,ulti VBX from different vendors. Would you rely your muti-miullion projkect on a 99 bucks VBX?

Foo Sayhow


From: umyin_at_mctrf.mb.ca (Qing Yin)

In <2sa4gt$qgi_at_raffles.technet.sg> sayhow_at_solomon.technet.sg (Foo Say How) writes:

>You have missed out Objectiview! With Roche (sp?) depository and its tie
>in with ADW Case Tools it certainly offer better solution than the other
>platform. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm not convinced. There are many reasons against it, too. And how do you explain that half of the job ads want PowerBuilder developers? (Well, PowerBuilder has annoying "features" also.)

By the way, in the original article, it's not fair to list C++ (and maybe VisualBasic also) among a bunch of specialized DB application tools.


From: marit_at_pz-oekosys.uni-kiel.d400.de

Don't forget the Interface Builder with the DB-Kit of NEXTSTEP.


From: paul_at_eunet.co.at (Paul Gillingwater)

UnifAce version 6.0. Very nice 4GL with cross-platform multiple database support.


From: marten_at_feki.toppoint.de (Marten Feldtmann)

 Do not forget:

         ST-V+PARTS+RDBI 2.0 from Digitalk
         VisualWorks+DB interface from Parcplace

----------------------------------------------------------------------

From: tom_at_fisp.NoSubdomain.NoDomain (Tom Losnedahl)

|> >>
|> >> And don't forget db-UIM/X from Bluestone |> >> |> >And don't forget SNAP from Template Software, Inc. either! It has much, much, |> >much more functionality than just a front end to an RDBMS!!

.... and dont't forget Client/Server Elements (Open Interface + DB Access) from Neuron Data either .....


From: blustone!kepler!bickel_at_uunet.UU.NET (Bob Bickel)

I read your note on the net asking for write-ups on different tools. Here's one for db-UIM/X:

Bluestone's db-UIM/X product gives developers the productivity they are looking for with Visual Programming, but is founded on being a pure C and C++ environment. It does NOT use proprietary 4GL's or scripting languages. Instead, developers can add their own C and C++ code, as well as generate clean, pure, portable C or C++ code. This gives developers the power and portability they need for production level applications.

db-UIM/X gives developers the ability to take advantage of four advanced technologies:

  • GUI Development
  • Object Technology
  • Client/Server Architecture
  • Relational Databases.

The key concept is the ability to "bind" database objects to user interface objects. For example, a pushbutton activate callback is bound to a Stored Procedure, Text fields are bound to Stored Procedure Arguments, and database results populate various Motif and add-on widgets such as text fields, scrolled lists, menus, matrix widgets, and Graph widgets. This binding process is done without 4GL's or proprietary scripting languages.

The db-UIM/X product includes the entire UIM/X product (or you can upgrade from UIM/X), with several additional editors and browsers. There are 5 key components to the tool:

  1. UIM/X - you get the entire UIM/X capabilities, including Builder Engine functionality. This gives it the best Motif GUI Builder capability on the market.
  2. Network Object Toolkit - various interfaces to browse network objects, and "bind" user interface objects to database objects.
  3. Object Request Broker - Conforms to OMG CORBA specification to provide a robust, transparent network architecture.
  4. db-UIM/X Network Services - a set of client side API's built on standard RPC mechanisms. Includes an API to customize widget population. Default widget population is included for all Motif widgets and XbaeMatrix and XRT/graph.
  5. C and C++ Code Generation - built on the same UIM/X capability, db-UIM/X adds the code automatically generated from the drag-and-drop programming of the Network Object Toolkit.

db-UIM/X has the following system requirements:

			V2.5(now)		V2.6(Summer)
			---------		---------
	Windowing	X11R5, Mot 1.2		same	
	Operating Sys	UNIX			same	
	Platforms	SUN,IBM,HP		same	
	Databases	Sybase			Oracle	
	Data Access	Stored Procedures	same, DSQL	



db-UIM/X is now available for demonstration from Bluestone, or any of our Resellers:

	Bluestone	blustone!info_at_uunet.uu.nt
			609-727-4600

	Black & White Software in the Western U.S.
			julia_at_blackwhite.com
			408-369-7400

	Protek		Europe
			pcash_at_protek.co.uk	
			44-628-75959

	Astec		Japan
			okada_at_astec.co.jp
			81-3-5261-5972


----------------------------------------------------------------------

From: se_at_gordo.sunquest.com (Steve Etchelecu)

Sybase's GainMomentum and BuildMomentum products look really great. Capabilities are tremendous.


From: bentz_at_blustone.uucp (Ray Bentz) Date: Wed, 1 Jun 1994 14:06:27 GMT
Newsgroups: comp.software-eng,comp.databases.oracle,comp.databases.sybase,comp.soft-sys.powerbuilder,comp.sys.windows.ms.programmer Subject: Re: PowerBuilder vs VisualBasic vs Oracle's CDE vs C++ vs SQLWindows vs ?

And don't forget db-UIM/X from Bluestone


From: paalti_at_oslonett.no (Paal Thingbo) Date: 31 May 1994 22:09:15 +0200
Newsgroups: comp.soft-sys.powerbuilder
Subject: Re: PowerBuilder vs Visua
Status: O

On 30-05-94, marten_at_feki.toppoint.de (marten feldtmann) wrote:

MF> Do not forget:

MF>         ST-V+PARTS+RDBI 2.0 from Digitalk
  >         VisualWorks+DB interface from Parcplace

Pluss:
     - JAM from JYACC
     - Paradox for Windows from Borland

----------------------------------------------------------------------

From: dxs_at_Unify.Com (Dale Shaver)

You may want to look into Unify VISION from us, Unify Corporation. Unify VISION is our fully graphical system. VISION is a database independent, cross-platform, object-oriented, graphical development system that allows you to develop fully functional database access applications on Unix (Motif / Openwindows), MS Windows or Windows NT, and deploy them everywhere, including Macintosh. VISION allows all components of an application (forms, toolbars, global functions) to be shared across many applications, and fully functional applications can be developed without one line of 4GL code.

If additional functionality is needed, the VISION 4GL script is very powerful, with over 250 statements and functions, and the ability to incorporate 3GL (e.g. C or C++) or other external functions into the 4GL language. An application has the ability, through Heterogeneous Database Access (HDA), to access tables from multiple data sources, e.g. Sybase, Oracle, Informix, Ingres, UNIFY 2000, or PC-based ODBC compliant data files, all at the same time.

For more information, and to receive a literature packet, please give us a call at the 800-number below.

Dale


From: blustone!kepler!bickel_at_uunet.UU.NET (Bob Bickel)

I read your note on the net asking for write-ups on different tools. Here's one for db-UIM/X:

Bluestone's db-UIM/X product gives developers the productivity they are looking for with Visual Programming, but is founded on being a pure C and C++ environment. It does NOT use proprietary 4GL's or scripting languages. Instead, developers can add their own C and C++ code, as well as generate clean, pure, portable C or C++ code. This gives developers the power and portability they need for production level applications.

db-UIM/X gives developers the ability to take advantage of four advanced technologies:

  • GUI Development
  • Object Technology
  • Client/Server Architecture
  • Relational Databases.

The key concept is the ability to "bind" database objects to user interface objects. For example, a pushbutton activate callback is bound to a Stored Procedure, Text fields are bound to Stored Procedure Arguments, and database results populate various Motif and add-on widgets such as text fields, scrolled lists, menus, matrix widgets, and Graph widgets. This binding process is done without 4GL's or proprietary scripting languages.

The db-UIM/X product includes the entire UIM/X product (or you can upgrade from UIM/X), with several additional editors and browsers. There are 5 key components to the tool:

  1. UIM/X - you get the entire UIM/X capabilities, including Builder Engine functionality. This gives it the best Motif GUI Builder capability on the market.
  2. Network Object Toolkit - various interfaces to browse network objects, and "bind" user interface objects to database objects.
  3. Object Request Broker - Conforms to OMG CORBA specification to provide a robust, transparent network architecture.
  4. db-UIM/X Network Services - a set of client side API's built on standard RPC mechanisms. Includes an API to customize widget population. Default widget population is included for all Motif widgets and XbaeMatrix and XRT/graph.
  5. C and C++ Code Generation - built on the same UIM/X capability, db-UIM/X adds the code automatically generated from the drag-and-drop programming of the Network Object Toolkit.

db-UIM/X has the following system requirements:

                        V2.5(now)               V2.6(Summer)
                        ---------               ------------
        Windowing       X11R5, Mot 1.2          same	
        Operating Sys   UNIX                    same	
        Platforms       SUN,IBM,HP              same	
        Databases       Sybase                  Oracle	
        Data Access     Stored Procedures       same, DSQL	
 
 
 

db-UIM/X is now available for demonstration from Bluestone, or any of our Resellers:

    Bluestone           blustone!info_at_uunet.uu.nt
                        609-727-4600

    Black & White Software in the Western U.S.
                        julia_at_blackwhite.com
                        408-369-7400

    Protek              Europe
                        pcash_at_protek.co.uk	
                        44-628-75959

    Astec               Japan
                        okada_at_astec.co.jp
                        81-3-5261-5972


----------------------------------------------------------------------

From: davidh_at_fsg.com (David J. Hane)

What about VPE (Visual Programming Environment)? VPE is marketed by a company that used to be called Market Focus, though I have heard they were acquired recently. I am learning Powerbuilder, but am not too overly impressed. VPE runs on Unix workstations and OS/2 (maybe others). It will let you build a nice GUI to a RDBMS. Good luck.


######################################################################

Section 2 - Visual Basic / Microsoft defense


From: bbeatty_at_sage.cc.purdue.edu (Brian Beatty)

If you choose more than one choose VB and Access. The languages are very similar and they both use ODBC drivers for data access.

if you do get VB get another program called VB Assist it will shave hours off development time.


From: nicodem_at_pacs.sunbelt.net

> a simple question. Access 2.0 has a version of basic, i believe.
> is it compatible with VB? same thing? marginally different?
> any cavaets in moving back and forth between apps? any time
> VB as a frontend to Access would be preferable to Access Basic?

You've asked perhaps one of the most common questions related to Access and Visual Basic. First, the answer is Yes: Access Basic is basically (no pun intended!) the same language as Visual Basic. To be specific, it's based on the common language being developed by Microsoft, VBA, which will be replacing various macro languages in their products that "work together".

The fundamental (there, I got around that!) language is identical. However, you won't be able to directly port applications from one to the other, simply because Access has some calls (methods, statements, etc.) that are unique to, and required by, the Access database structure. Similarly, Visual Basic has built-ins that particularly address the GUI and related topics.

Actually, let's even confuse things a bit more: not only is the *language* the same, but the *database* is the same! Both use the Jet 1.0 engine (well, versions will change as you upgrade the products, but it's the same database engine). Which means that Visual Basic can *directly* address Access .MDB databases.

I won't even *begin* to get into how you choose which to use. There have been countless articles (including in the various Microsoft publications). Perhaps one of the best, and most recent, was an issue of Visual Basic magazine that was totally dedicated to this topic (i.e., Visual Basic vs. Access); I think it was last month's (or the previous). If I had to sum up the choice for myself, it would be: what am I doing more of (i.e., database, or application programming), and how much of what I'm doing is fairly "standard" vs. how much requires custom coding. (For instance, if your database application is predominantly standard querying and reporting, Access alone may fill the bill. But if you find yourself writing more and more Access Basic code, and feeling less and less satisfied with the User Interface, you might write a Visual Basic front-end.)


From: wang_at_ortho.cor.ssh.edu (Sophie Wang)

Hello, Guys:

I extremely want to express my opinoin around the question :"Which one is best" in spite that I only use some of them, i.e., PowerBuilder, VisiualBasic, and MS Access 2.0.

At first, like you, we hesitated about these tools, which one we should use to develop our front-end of EIS.After several trials, we finially decided to utilize MS VisiualBasic. Why? It is very flexible to design and implement your own savor GUI. If you feel comfortable Windows Programming, you will like it very much. It grants programmers a lot of flexibilties and utilities to let them code their GUI at their own. But, on the contrary, PowerBuilder binds programmers' foot and hands and it is confused to offer some functionalityies. Compared with PowerBuilder, Visiual Basic is easier to learn and to use. I may say that PowerBuiler is nothing more than a more powerfull QBE. You know what kind of jobs a QBE can do and what limitations are.

If you want to develop your own GUI for your own database system based on SQL Server or Oracle, I extremely recommend VB to you to save your time and make your life easier. If you insist on using PB, you definitly will feel frustrated after first several tries.

By the way, you can call me at the number : 412-623-3006 if you wants to know details about them.

P.S. I have rich experience in developing large system based on a centralized database and associated user interfaces, for example, I once used CSP(Cross System Products) , ISPF(PDF), and DMS/CMS. All these user interface development tools are invented by IBM from its mainframe users. I used them along with DB2 and SQL/DS. THerefore, I know what kind of front-end tools are easier and flexible to use and what kind of features of them are what we need from programming pointview.


From: neff_at_anna.Stanford.EDU (Randall Neff)

If you are building an application that only talks to one database, then use the tool that comes from the that same vendor. Future improvements to the database will be quickly implemented in their own tool.

If you are developing on Windows 3.1, Win32 or NT, with multiple vendor databases, then use Visual Basic with the Open database interface thingy. Because MicroSoft is going to continuously change the interfaces in future Windows and only their products will keep up. Also there is an expanding market for third party VBXs to drop into VB, including spreadsheets, text editors and graphing.

######################################################################

Section 3 - Power Builder


From: RI_CLARK_at_delphi.com

Thanks for a chance to express my opinion about these two products. I've worked with Powerbuilder for about a year and own both the Desktop and Enterprise versions. I've recently been working on a project using Forms 4.0.

IMHO Powerbuilder is vastly superior to Forms 4.0. Not only is it easier to learn and much more intuitive -- it does what you'd expect a GUI generator to do.
Recently I wanted to highlight the selected row in a Master Default Block so that the user would know which row is currently selected without my having to copy it to another field somewhere on the form. This is a piece of cake for Powerbuilder but I couldn't figure out how to do it in forms. I called Oracle, waited the requisite 10 minutes and was told that this isn't currently supported -- "although we get a lot of calls about it"!

Another thing that has me tearing what little hair I have is trying to work with ASCII files on the client using Forms 4.0. Again, this is almost a trivial problem for PowerBuilder -- I can import data from a file into a data window or use scripts to open, read and write files directly. I've been able to WRITE ASCII files from Forms 4.0 by building my records in Oracle tables and using HOST() to run SQL*Plus to spool the results of a select statement to a file. I have not, as yet, been able to figure out how to READ a flat file into a Forms application.

If I had the option, I'd never bother with Forms 4.0 for Windows applications using Oracle -- I'd use Powerbuilder.

Thanks again. I'm looking forward to seeing the results of your survey.


From: slade_at_fnma.COM (Benjamin G. Slade)

I know nothing about PowerBuilder except that it's object oriented and currently the most politically popular.


From: u77645_at_sys30030.orl.mmc.com (Marshall Sandene)

Like that guy who liked the Remington shaver so much he bought the company, I just got Powerbuilder Desktop for my machine at home. I use the Enterprise edition at work. Except for the big-boy database interfaces like Sybase and Oracle and the programmer tools and prebuilt objects it is virtually identical to the enterprise edition. You have to by the runtime deployment kit separately if you want to distribute your application. Last month they had a special where if you bought the Desktop software they would throw in the deployment kit for free (a $249 value or so - retail of course). I just got mine the other day. I don't know if this deal is still in effect, but it was one of the incentives that coerced me into reciting the mystical VISA numbers into the phone.

Watcom seems to be a pretty good database although one of the first error messages I got from it had a spelling error. An evil omen? Things that make you go hmmm... Oh, weell, I cen't spill that weell iether. Haven't used Watcom much yet since I use Sybase at work. Why drive the VW when you've got a porsche?


From: birzniek_at_nova.umd.edu (Gunther Birznieks)

>>One of the nice things about Powersoft is that they publish updates to
>>their programs once a month to fix all the latest bugs. Its like
>>pulling teeth to get a software fix from Borland or Microsoft for
>>Visual Basic.
 

>How do you get these updates?

You simply download them off their BBS or compuserve.

######################################################################

Section 4 - Gupta's SQLWindows


From: tasallot_at_mprgate.mpr.ca (Mathew Tasalloti)



Computer Select, August 1993
* Full Text COPYRIGHT Ziff-Davis Publishing Company 1993.

Windows Sources June 1993 v1 n5 p180(4)


Move over, PowerBuilder! SQLWindows 4.0. (Gupta Corp.'s graphical programming tool for Windows) (Software Review) (Hands On: Software) (Evaluation)

Author
Watterson, Karen



Abstract

Gupta Corp's $1,995 SQLWindows version 4.0 graphical programming tool for Windows applications features object-oriented functions in the latest release that are particularly well suited to developing workgroup applications. The optional Team Windows workbench competes with KnowledgeWare's ObjectView 2.0 with Object Repository, and it surpasses the workgroup features of PowerBuilder 2.0. Programs are created with a combination of visual programming and intuitive outline-style coding; the company's Quest has been integrated in the new version as a table window for ad hoc database access and reporting. Single and multiple inheritance, encapsulation, polymorphism, and user-defined window and function classes are supported, and the new report writer supports crosstab reports, form letters, and multicolumn labels. SQLWindows 4.0 is an excellent tool for Windows SQL client/server database development. The Corporate Edition, with Quest, Team Windows, and Express Edit, costs $3,! 495.

Full Text
Related article: SQLWindows 4.0

Gupta Corp. 1060 Marsh Rd. Menlo Park, CA 94025 800-876-3267; 415-321-9500; fax, 415-321-5471

List Price: Standard Edition, $1,995; Corporate Edition (with Quest, Team Windows, and Express Edit), $3,495

Requires: 386-based PC or better, 4MB RAM (8MB recommended), 15MB (approx.) hard disk space, Windows 3.1

DDE Support: Client and server

OLE Support: Client and server Runtime: Free

SQLWindows 4.0 and TeamWindows are state-of-the-art, object-oriented tools for developing client/server applications. SQLWindows is a mature product that competes squarely with PowerBuilder and ObjectView. If you need multi-programmer support now, look at SQLWindows with TeamWindows and compare it to KnowledgeWare's ObjectView and Object Repository.

SQLWindows was one of the first graphical programming tools for Windows applications, originally developed as a front-end tool for Gupta's SQLBase Server. SQLWindows' popularity spread as Gupta provided additional back-end support for other database servers such as SQL Server and Oracle.

The beta version we examined included significant enhancements that make SQLWindows an object-oriented tool with trendsetting features for work-group development. SQLWindows' optional workbench, called Team Windows, will compete squarely with KnowledgeWare's (formerly Matesys's) ObjectView 2.0 with Object Repository, leapfrogging the workgroup features in PowerBuilder 2.0.

Despite its new object-orientation, SQLWindows developers continue to create programs with a combination of visual programming and intuitive outline-style coding. SQLWindows, like most robust 4GLs for developers, does not offer point-and-click, codeless programming. Gupta's Quest (for ad hoc database access and reporting) has been integrated into SQLWindows 4.0 as a table window.

SERVER SUPPORT SQLWindows 4.0 ships with a single-user copy of SQLBase Server for Windows, Gupta's own DBMS, giving users the option of storing data locally and making it easy to develop client/server applications for SQLBase. SQLWindows can also connect to HP AllBase/SQL, IBM AS/400, IBM DB2, Informix, Novell NetWare SQL, Oracle (Oracle 6 only at press time, Oracle 7.0 later), IBM OS/2 DBM, Microsoft and Sybase SQL Server, Cincom Supra, and HP Turbo Image databases. Additional support for Ingres and DEC Rdb should be available shortly. Connecting to remote databases requires using router or gateway software from Gupta. Client router software for the PC costs $250 per user, with volume pricing available.

Gupta's approach differs from Powersoft's, since PowerBuilder 2.0's entry-level version ($1,495) ships with XDB and SQLBase drivers. The Premium Edition ($3395) supports HP AllBase/SQL, Informix, Oracle, and Microsoft and Sybase SQL Servers. A special DB2 version of PowerBuilder ($3,895) requires the Micro Decisionware DB2 Gateway. Although Powersoft doesn't require purchasing per-user routers or gateways, it does charge a server-based runtime of $695, $995, or $1,495 for the entry-level, premium, and DB2 versions respectively.

NEW FEATURES Although SQLWindows maintains some of its modular architecture with separate components for SQLWindows itself and Report Windows, SQLWindows has a more integrated feel that streamlines application development.

Version 4.0 supports single and multiple inheritance (where objects inherit features from previously defined objects, saving coding), encapsulation (combining data and actions), polymorphism (another way of reusing code), and user-defined window and function classes (a form of user-defined objects). PowerBuilder 2.0, with its inheritance and user-defined objects, has been outclassed, at least temporarily, in the area of object-orientedness.

Beyond the streamlined development environment and SQLWindows' new object orientation, developers will find a host of timesaving enhancements. For example, SQLWindows 4.0 introduces an innovative tiered approach to DDE links, offering both simple and advanced connections, and Gupta includes an auto-conversion program to update existing SQLWindows 3.1 applications.

SQLWindows' report writer, always considered top-notch, has also been improved and is now a full-fledged two-pass report writer, supporting crosstab reports, form letters, and multicolumn labels. SQLWindows' report writer is far stronger than the first iteration of a report writer that shipped with PowerBuilder 2.0, another advantage over the PowerSoft product.

WINDOWS SUPPORT SQLWindows, like PowerBuilder, also supports MDI (Multiple Document Interface), including multiple Outline Windows. Since the Outline Window is where programmers do SAL (SQL Application Language) coding, MDI makes it easy to work with different views of application code simultaneously.

SQLWindows 4.0 lets programmers create custom toolbars and pop-up menus that are defined at runtime. Toolbars are typically alternate menus consisting of icons and are often displayed just below an application's main menu. Although we prefer to see textual descriptions of what toolbar push buttons do displayed automatically at the bottom of the screen on the status bar when the mouse moves over the push buttons, Gupta lets you click on the push button, read the text that appears in the window's status bar, and without releasing the mouse button, move the mouse pointer off the push button. You can also display bitmaps on your own icons. It's theoretically possible to do all these things with PowerBuilder, too, by creating your own custom controls, but the process is far less automated.

Named menus let you define pop-up menus that are shared between windows in an application. You can also use named menus to create pop-up menus that can appear anywhere on the screen. A named menu can have two types of children--Menu: and Windows Menu:--where the name of the menu goes after the colon. Pop-up menus only have a title.

A Windows Menu can refer to any of its own named menus or any global named menus. An MDI child window can also refer to named menus in its MDI window parent. You can only use named menus for top-level pop-up menus, not for cascading menus in a pop-up menu. You can create pop-up menus at runtime with the SalTrack-PopupMenu function. Here's a fragment of SAL code that would invoke an Edit pop-up menu when the user clicks the mouse button:

On SAM_Click Call SalTrackPopupMenu ( hWndForm, 'menuEdit', TPM_CursorX ! TPM_CursorY ! TPM_CenterAlign, 0, 0 )"

Another new feature we like is SQLWindows' handy tool to nationalize SQLWindows applications. You use Express Edit to convert user interface strings and internal strings to another language. Express Edit also extracts resources that you can use later with revised versions of an application.

USING SQLWINDOWS 4.0 The default SQLWindows desktop includes an outline window that can be expanded and collapsed in true outline style and a design window--complete with ToolBox objects--where developers lay out the user interface. To inspect or change any object's properties, developers double-click on the object to invoke the Customizer.

An application outline has many sections. At the "top" are Design Time settings, included objects, and global declarations. All SQLWindows outlines come with "stub" sections for top-level windows (form, dialog, and Quest table windows, for example). These correspond to the visual objects that are menu picks in the Design Window. Ultimately, there is a one-to-one correspondence between all objects in the Design Window and items in the Outline Window.

Although SQLWindows doesn't have built-in charting and graphing, it does support OLE both as an OLE client and server--and it's one of the few development tools that does. Gupta has also done a good job integrating OLE function calls into its own programming language, SAL.

SQLWindows' Debug Dialog Box has Evaluate and Result windows as well as buttons to Watch Msgs, Watch Vars, Continue, Step, Step Over, and Abort.

You can also use the optional Run!Animate or Run!Slow Animate for debugging.

TEAM WINDOWS FOR PROGRAMMING GROUPS TeamWindows promises to bring significant enhancements to SQLWindows work-team development in organizations that use multiprogrammer development teams to create client/server applications. TeamWindows helps you organize development efforts by project. In addition to the normal sorts of tasks associated with code check-in, audit functions, and so on, TeamWindows also lets you associate standards and screen templates with projects.

TeamWindow's and PowerBuilder's support for development teams differs. TeamWindows is a separate product that has a project-management feel. PowerBuilder has an integrated check-in/check-out system for controlling object resources in the Library Manager, but it doesn't provide source-code or version control.

The core of TeamWindows is a repository database and data dictionary that can be maintained on any DBMS supported by Gupta. (The initial shipment, however, will only support a repository that uses Gupta's own SQLBase server.) The data dictionary contains information about the structure of application databases--everything from table and column names and table relationships to field data types along with any display formats, default values, and validation criteria. The TeamWindows data dictionary can be populated directly from the back-end database's system catalog or can be created directly in TeamWindows. Gupta, like Powersoft, is working with CASE vendors to extend TeamWindows' interoperability to leading CASE tools.

WHAT'S MISSING We would like to see built-in support for charting and graphing, along with default Quick Report and Quick Form options. (A new Quest Forms Activity, scheduled to ship a few months after SQLWindows 4.0 does, will reportedly help address the latter.) Broader back-end support would be useful, and we hope Gupta will revise its per-user fees ($250 per PC) for router software needed to connect to any back end other than SQLBase.

SUPPORT SQLWindows 4.0 will include seven manuals: SQLWindows Programming, Technical, Function Reference, and What's New Manuals, ReportWindows and Express Edit User Guides, and a Quest Windows tutorial. Additional TeamWindows documentation will include a Starter Guide, a User Guide, and a Template Design Guide. We have always been impressed with the quality of Gupta's documentation and rate it as "best of breed."

Frankly, Gupta doesn't have the best reputation for support, but it has invested in this area over the last 18 months. Gupta provides 90 days of free telephone and BBS support and maintains an active BBS for maintenance plan subscribers. It is reportedly planning to host its own forum on CompuServe soon. Gupta and its authorized training partners teach a five-day class on SQLWindows ($1,595), and Gupta also sells a comprehensive videotape version of this training.

CONCLUSION If your problem is development of a Windows SQL client/server database, SQLWindows 4.0 is a great solution. It has surpassed PowerBuilder in terms of object-orientation, workgroup development support, and report writing. Since projects of this type are so complex and so specialized, we recommend that you examine your needs and determine whether SQLWindows is right for you. We think it's a great development tool.

Type
software review
evaluation

Company
Gupta Corp.

Product
SQLWindows 4.0

Topic
Evaluation
Program Development Software
Object-Oriented Programming
Applications Programming
Data Base Management Systems

Record#
13 736 654.


From: oliver_at_sun.subito.de (Oliver Kuhn)

>In article <2tcku8$5h2_at_nwfocus.wa.com>, darkwind_at_coho.halcyon.com (C.
>Joseph Bridwell) writes:
 

>>My company has recently informed me that I will be working with
 GUPTA
>>over their LAN and WAN sometime starting within the next 6 months.
 I'd
>>like to prepare myself as much as possible for this. Has anyone on
 here
>>worked with GUPTA? What are the good and bad points? What are the
>>pitfalls?
 

>We're beginning to use the Gupta tools (SQLWindows, SQLBase, Quest,
>etc.) as our intro to Client/Server and PC programming. Not sure
>which aspect of Gupta you'll be working with but took the liberty of
>posting your message on the Gupta Forum on CompuServe with a request
>that users e-mail you their comments. I would also suggest that you
>might want to join their forum, either on CompuServe (GO GUPTA) or
>via Internet into CompuServe.
 

>My experience so far is that SQLWindows has a longer learning curve
>than PowerBuilder but that the product is more powerful. SQLBase
>currently lacks all the bells and whistles of, say, Oracle or Sybase,
>such as triggers, RPC, etc., but that they're coming with 6.0. I
>might question the scalability.

Hi,
we've been using Gupta for about 2 years. SqlWindows is a quite powerfull 4GL. If you use the OO-Features of Gupta, you will be able to create applications quite fast. SQL - handling is very easy. On the other hand sometimes SqlWindows behaves rather strange. You will have to use workarounds to solve some problems. Most Bugs were fixed on the last version 4.1.0. A problem is also the lack of some data structures. There are no pointers, so there's also no possibility of using dynamic memory management. In earlier versions there were'nt even structs. Now you can use classes to do that. There are 2 SQL-frontends. SqlTalk is quite simple and small, Quest is much more comfortable.
We use both Oracle and SqlBase. Oracle has much more features and is better in nearly all applications. The single-user version of SqlBase that runs as a windows program is usable. We had also a multi-user version that we liked to use on a Sun, but after a few days of trying we gave it up. There were so many problems when using it with multiple users, but if there's only one user, we don't need a database server on a remote machine. We use the single-user version of Gupta for presenting our software. Some points are quite strange, e.g. there is only one user, called sysadm, who is allowed to create new users, but everybody who has DBA-rights can get the password of sysadm. Security is not supported very efficiently, so there is one system view which enables you to read the passwords of all users. You see, there's light and there's darkness.

######################################################################

Section 5 - Other summaries


From: Steven Semels <srs_at_pencom.com>

as a technical recruiter, i speak to people all day who are using the products that you're comparing. here's the feedback that i've gotten lately:

*vc++:  becoming the c++ language for mswnds;replacing borland's c++ 
*powerbuilder:  good for now but very buggy;future looks better
*vis basic:  easy to use but limited
*ms access:  better than sdk;nice for limited desktop apps
drop me a note when you get results-i'd love to hear what others have to say!

thanks,
steve


From: Gunther Birznieks <birzniek_at_nova.umd.edu>

Inserted is a post I made last month on one of the subs detailing the differences of Powerbuilder vs Visual BASIC. Since people ask the question all the time (regarding Client/Server development) I saved the post.

Newsgroups: comp.lang.basic.visual
Subject: Re: Visual Basic Versus Powerbuilder (???) References: <2mi75uFmhs_at_uni-erlangen.de>

In <2mi75uFmhs_at_uni-erlangen.de> ua193_at_fim.uni-erlangen.de (Stelios Manias) writes:

>AI> I would appreciate input on the Visual Basic Versus PowerBuilder
>AI> subject. I used to be a Mainframe Programmer and now I am
>AI> debating between Visual Basic and PowerBuilder.
>AI> I played with both and both of them appear to do the same
>AI> things.. What is the difference between those two and what are
>AI> the pro's and con's ..
>AI> Any input would be appreciated
>AI> Thanx
>AI> Stelios Manias
>AI> --
>--

While they do the "same thing" in general (GUI Programming), PowerBuilder definately has a Database related edge as well as an applications programming edge over Visual BASIC.

Microsoft, for example, advertised Visual BASIC 3.0 as coming with the ACCESS database engine and finally built in ODBC support for SQL Server and the like with the Holy Grail "Database Custom Control".

Unfortunately, these prove to be quite hard to deal with as well as slow and not easy to customize for client-server programming. For example, I wrote an application initially using straight Dynasets and Data Aware controls on VB 3.0 pro and found the application to be quite slow. I reimplemented it in Visual BASIC using direct ODBC Calls (downloaded the interface direct DLL calls off of an FTP site on the internet). This *finally* gave me the performance I needed. Of course, to get the performance I had to forgo Data Aware controls and high level programming and had to make my own low level ODBC DLL calls. This made my application fast (yay!) but paid for it in development time (boo).

I will say however that Q+E MultiLink VB is a Fast interface (much faster than VBs built in Data aware controls!) for Client-Server programming. But it is a 3rd party product -- not integrated. I have no comments on Integra VDB since I have not had experience with it and how it might purport to work.

However, even with MultiLink VB (I used the one that was current as of last summer -- I am aware they have an update that might change this) you do not get the control over Client-Server that you get with PowerBuilder unless you, again, settle for low level programming.

PowerBuilder on the other hand supports, for each datawindow control, a multitude of database options such as being able to update via timestamp changes, via checking all updateable columns, only columns that were changed and the key column, etc... Whether you want updates to be done with the update command or with an insert/delete combination, whether you want Retrieve as neeeded or Retrieve all etc... Some of the above is available with MultiLink VB but not all unless you go low level again. In the documentation I received for MultiLink VB I only saw one reference in a READ ME file about the concept of Retrieving locally vs Retrieving as needed in data controls attached to a query.

PowerBuilder also offers a "Database Schema" view where you can pull up tables and have them connected via "case-like" arrows and lines depending on your primary keys and foreign keys... As well as other graphics showing indexes you have on your tables in a database. It also stores in a database repository all sorts of rules and information (meta data) about your tables that you use in the applications you write. This is very powerful and saves a lot of time.

VB Pro offers nothing near this in its stock version.

PowerBuilder offers true visual object inheritance. I Can make a Window in PowerBuilder or a Button (like a close button for a form) or a Menu and I can easily create other Visual Objects that INHERIT previouosly made forms. This differs from simply COPYING forms when you are done with one and then editing it in that you can change the original ANCESTOR form(window or other visual object) and have all changes reflected in the descendants -- It even supports Private/Protected/Public variables within the inherited hierarchy just like C++ Class variables and procedures. This may not seem like a big advantage now, but trust me, when you start programming a large application, inheritability of objects even within ONE application (Not to mention future ones!) is quite a boon to my productivity.

At any rate, on the surface PowerBuilder may seem like it costs a lot of money (It does cost a lot of money! Although you can get it down in price signifigantly if you can do GSA pricing), but when you consider that to do everything that PowerBuilder does internally you will have to waste a lot of time doing low level programming in Visual BASIC (I thought the reason to go to VB was so you wouldnt have to spend time programming so much) plus buy a lot of 3rd party libraries to get decent Database functionality and support that PowerBuilder has built in. At that point, the initial "high cost" of PowerBuilder is just an "upfront cost" that can easily be thought of as equivalent to Visual BASICs meager upfront cost PLUS VBs "Hidden Costs" in programmer productivity and needing 3rd party tools to accomplish similar tasks.

Where I work, by the way, we use Visual BASIC actively for Data Acquisition products and other things that are not Client-Server specific. VB definately has its uses but if you are a site that has a Client_server database, it just does not make the greatest sense to skimp on developers tools.


From: mag3_at_netcom.com (M. Arnold Graham III)

m >Hugeng (7351.3557_at_compuserve.com) wrote:
m >: In article <CqGuoF.Jo_at_world.std.com>, rtj_at_world.std.com (RTJ Corporat
m > says:
: >
m >: Well, I prefer to stick with Microsoft. Since every future is depend 
m >: on Bill Gates hand. Do you know about OCX (Ole Custom Control) ?
m >: They do this because Microsoft is planning to port VB to 32 bit 
m >: environment (Chicago, Daytona). I know and experience in PowerBuilder
m >: They have much wider, and sometimes easier to understand than VB.
m >: But Is Powersoft has that kind of Power to rival the Microsoft ? Not 
m >chance, 
m >: Man. You better take the safer road - Sticking with Microsoft. 
m >: Bye..know.

: >Cordially
: >Hugeng Widjaja

m >Recently, Powersoft, the makers of Powerbuilder, acquired Watcom, the 
m >undisputed quality leader in optimizing compilers for DOS/Windows. Watc
m >may not be as big as Microsoft, but they are universally acknowledged f
m >their technical strength. 
m >The expertise that they bring to Powersoft could well make the differen
m >between Powerbuilder being an also-ran and a tool that is constantly on
m >the leading edge, like Watcom's compiler technology.

I prefer to see a world where both tools exist together. I see Visual Basic being used for the "quick and dirty" things that don't serious data base manipulations etc. and can be developed very quickly. I see Powerbuilder for the more long term, heavy, full fledged, data base intensive applications (ie. something for which you might have a large CICS/DB2 mainframe system).


From: Hans Forbrich <forbrich_at_tibalt.supernet.ab.ca>

Our experience, based on starting our front-end upgrade 1 year ago...

Our app - HRMS/Pay/Pension system w/ front-end on Windows & back-end under UNIX/Oracle - has over 500 UI forms for all aspects of the corporate requirements. (Typical user accesses about 10 of them - lots of scope in app, lots of optional subsystems). Packaged as about 45 exe's.

PowerBuilder

  • not mature at that time, lost out
  • my personal preference, if I had to start over

VB (v3) using Q+E's Multilink/VB

  • this is our winner
  • We are satisfied with both the flexibility & performance.

MS Access

  • limited in compatibility
  • generally needs additional drivers for

C++

  • lots of lead time in learning concepts.

Oracle's CDE

  • slow, performance wise
  • memory hog

Hope this helps


From: proffitt_at_mdd.comm.mot.com (Robert Proffitt) Organization: Motorola - Wireless Data Group; Richmond, BC

Ok, here's a quick feedback.

: PowerBuilder                   : Haven't seen it.
: VisualBasic                    : Great stuff. I use it.
: MS Access 2.0                  : Need better runtime price.
: Oracle's CDE (Forms e REports) : Pricey
: C++ (Visual C++, Applications Framework, ProtoGen) : Good stuff.
: SQL*Windows                    : Seen it, like, but not using.

Me? Just a small time database dev'r. Price seems to be a big issue since 99% of the PC based systems I deal with are from 1 to 5 users.


From: Gunther Birznieks <birzniek_at_nova.umd.edu>

Inserted is a post I made last month on one of the subs detailing the differences of Powerbuilder vs Visual BASIC. Since people ask the question all the time (regarding Client/Server development) I saved the post.

>AI> I would appreciate input on the Visual Basic Versus PowerBuilder
>AI> subject. I used to be a Mainframe Programmer and now I am
>AI> debating between Visual Basic and PowerBuilder.
>AI> I played with both and both of them appear to do the same
>AI> things.. What is the difference between those two and what are
>AI> the pro's and con's ..
>AI> Any input would be appreciated
>AI> Thanx
>AI> Stelios Manias
>AI> --
>--

While they do the "same thing" in general (GUI Programming), PowerBuilder definately has a Database related edge as well as an applications programming edge over Visual BASIC.

Microsoft, for example, advertised Visual BASIC 3.0 as coming with the ACCESS database engine and finally built in ODBC support for SQL Server and the like with the Holy Grail "Database Custom Control".

Unfortunately, these prove to be quite hard to deal with as well as slow and not easy to customize for client-server programming. For example, I wrote an application initially using straight Dynasets and Data Aware controls on VB 3.0 pro and found the application to be quite slow. I reimplemented it in Visual BASIC using direct ODBC Calls (downloaded the interface direct DLL calls off of an FTP site on the internet). This *finally* gave me the performance I needed. Of course, to get the performance I had to forgo Data Aware controls and high level programming and had to make my own low level ODBC DLL calls. This made my application fast (yay!) but paid for it in development time (boo).

I will say however that Q+E MultiLink VB is a Fast interface (much faster than VBs built in Data aware controls!) for Client-Server programming. But it is a 3rd party product -- not integrated. I have no comments on Integra VDB since I have not had experience with it and how it might purport to work.

However, even with MultiLink VB (I used the one that was current as of last summer -- I am aware they have an update that might change this) you do not get the control over Client-Server that you get with PowerBuilder unless you, again, settle for low level programming.

PowerBuilder on the other hand supports, for each datawindow control, a multitude of database options such as being able to update via timestamp changes, via checking all updateable columns, only columns that were changed and the key column, etc... Whether you want updates to be done with the update command or with an insert/delete combination, whether you want Retrieve as neeeded or Retrieve all etc... Some of the above is available with MultiLink VB but not all unless you go low level again. In the documentation I received for MultiLink VB I only saw one reference in a READ ME file about the concept of Retrieving locally vs Retrieving as needed in data controls attached to a query.

PowerBuilder also offers a "Database Schema" view where you can pull up tables and have them connected via "case-like" arrows and lines depending on your primary keys and foreign keys... As well as other graphics showing indexes you have on your tables in a database. It also stores in a database repository all sorts of rules and information (meta data) about your tables that you use in the applications you write. This is very powerful and saves a lot of time.

VB Pro offers nothing near this in its stock version.

PowerBuilder offers true visual object inheritance. I Can make a Window in PowerBuilder or a Button (like a close button for a form) or a Menu and I can easily create other Visual Objects that INHERIT previouosly made forms. This differs from simply COPYING forms when you are done with one and then editing it in that you can change the original ANCESTOR form(window or other visual object) and have all changes reflected in the descendants -- It even supports Private/Protected/Public variables within the inherited hierarchy just like C++ Class variables and procedures. This may not seem like a big advantage now, but trust me, when you start programming a large application, inheritability of objects even within ONE application (Not to mention future ones!) is quite a boon to my productivity.

At any rate, on the surface PowerBuilder may seem like it costs a lot of money (It does cost a lot of money! Although you can get it down in price signifigantly if you can do GSA pricing), but when you consider that to do everything that PowerBuilder does internally you will have to waste a lot of time doing low level programming in Visual BASIC (I thought the reason to go to VB was so you wouldnt have to spend time programming so much) plus buy a lot of 3rd party libraries to get decent Database functionality and support that PowerBuilder has built in. At that point, the initial "high cost" of PowerBuilder is just an "upfront cost" that can easily be thought of as equivalent to Visual BASICs meager upfront cost PLUS VBs "Hidden Costs" in programmer productivity and needing 3rd party tools to accomplish similar tasks.

Where I work, by the way, we use Visual BASIC actively for Data Acquisition products and other things that are not Client-Server specific. VB definately has its uses but if you are a site that has a Client_server database, it just does not make the greatest sense to skimp on developers tools.


>From: umyin_at_mctrf.mb.ca (Qing Yin)
>Subject: Re: PowerBuilder vs. ObjectView
>Organization: The University of Manitoba

stewartw_at_cognos.COM (Stewart Winter) writes:

> One shouldn't look at inheritance or polymorphism as a requirement
>for a product. What you should be looking at is how effectively the
>product provides reuse. Sometimes inheritance (especially if not provided
>properly) does not really improve reuse, and hence does not improve the
>time it takes to produce an application or the end result.

Inheritance is indeed a very useful thing in my application. We have many tables that are pretty much handled the same way. You know, retrieve, update, delete, to and from a single table at a time. So all I need to do is build a main window that has update, delete buttons. Then inherite it to assign different datawindow.dataobject.

To give a comparison, we have to deal with the same database in Sybase APT front-end. There's no inheritance there, and we just copy everything from a model screen. We often find bugs or make minor modifications to the application, and it's such a pain to go through all the screens and make the same modification.

In general, I think it's pretty safe to say that inheritance is a plus factor in a product. It's like to say that it's generally true that modularity is a good thing in software development.

--

----------------------------------------------------------------------


>From: v045101_at_procyon.stortek.com (Sean Stasica)
>Subject: Re: PowerBuilder vs. ObjectView
>Organization: Storage Technology Corporation
SteveYan wrote:
> In article <2pubu9$4c3_at_canopus.cc.umanitoba.ca> umyin_at_cc.umanitoba.ca (Qing Yin) writes:
> >In <gavin.767657718_at_rs6.fm.arizona.edu> gavin_at_rs6.fm.arizona.edu (Gavin Stark) writes:
> >>Can anyone tell me about "ObjectView" from KnowledgeWare? There is an add
> >>in PC Week of them basically knocking PowerBuilder, and I'm wondering how
> >>their environment stacks up against PB?
> After a 17-week evaluation of GUI development tools, we found PowerBuilder
> to be the best of the breed. ObjectView is a good tool but it does have
> its shortcommings:

> 1) ObjectView does not support inheritance or polymorphism.
> Actually, the only thing object-oriented about the product
> is its name.
> 2) It has virtually no 3rd-party support
> 3) It had an aweful Report Writer in the old 2.0 version. The
> current version (3.0) appears to have address that issue,
> but not enough feedback has come back to verify this.
> 4) The individual components are not well-integrated like PB.
> 5) You still have to paid for runtime licenses.
> 6) No Mac port in the very near future.

> The really nice thing about ObjectView is that it is fast. Both the
> development and runtime environments run circles around PB and SQLWindows.
I am looking at a brochure from KnowledgeWare that states "ObjectView applications can be distributed freely without additional royalty or run-time fees." I don't really know where the confusion is, unless they do try to mislead potential customers by stating that the applications can be distributed freely, but charge each user for a runtime version of ObjectView. In the case of PowerBuilder, it can create stand-alone executables, so the users do not need any runtime environment (like one does with something like Oracle Forms 4.0). One clue we may have is that ObjectView is going to have runtime environments on platforms such as UNIX (SunOS and HP/UX), Mac system 7, Chicago, and NT, although the development environment will remain on MS Windows. Does anyone have any definitive answers on this?? ----------------------------------------------------------------------
>From: jemiller_at_netcom.com (John Edward Miller)
>Subject: Re: VB vs PB: What Do I Do?
>Organization: NETCOM On-line Communication Services (408 241-9760 guest)
: |> I've finally been able to free myself from supporting : |> mini-computer applications. PC applications are an : |> area of interest. However, I don 't want to get caught : |> up in testing multiple platforms. : |> : |> Our department whiz says that PB is not ready for : |> prime time client development so he recommended : |> VB. He said that Powersoft has a great ad campaign : |> but it is still not quite ready. There's no question that PB is buggier/less stable than VB. On the other hand, there's no question that VB's overall design (at least as of 3.0) has some huge conceptual holes in it that PB doesn't. ----------------------------------------------------------------------
>From: tasallot_at_mprgate.mpr.ca (Mathew Tasalloti)
>Subject: Re: Client/server - C++ or 4GL (MS Windows)?
>Organization: MPR Teltech Ltd.
In article <CpJ0ty.2yu_at_mdis.co.uk> mab_at_mx1.uk.mdis.com (Martin Bradford) writes:
>From: mab_at_mx1.uk.mdis.com (Martin Bradford)
>Subject: Re: Client/server - C++ or 4GL (MS Windows)?
>Date: Mon, 9 May 1994 08:27:33 GMT

>Lee Sailer (sailer_at_esr.hp.com) wrote:
>: Kurt Schmidt (slores_at_goshen.connected.com) wrote:

>: > My quandary is as follows: I understand that tools like PowerBuilder, maybe
>: > others like SQLWindows, can handle DLLs for processing that they cannot do
>: > basically. I am thus thinking that it might make more sense to develop what
>: > can be handled, such as data management and c/s layer, in one of the 4GL
>: > tools, and what it does not support directly, by developing DLLs to do that.

>: Seems right to me. Don't reinvent the user interface wheel.

>: And, either the DLL's can do the work themselves, or they can forward it
>: to some computation server elsewhere, using some IPC such as a socket or
>: RPC.

>: --
>: lee
>In principle this is correct but do remember that in many cases, the interface
>between the 4GL and the DLL is quite restrictive - DLL's are fine for plugging
>minor gaps in functionality but, if there is a major mismatch between
>requirements and functionality, it may be very difficult to fix with DLL's.
>You really must look very carefully at the final requirements and satisfy
>yourself that you can achieve what is needed before you go too far down
>the development path. Most 4GL's can only support a single application
>model and the addition of DLL's will not change that.

>Regards,

>Martin Bradford.
Agreed. I designed and implemented most of our front end clients in C++ before becoming frustrated with the ongoing battles with 3rd party widgets and tools. We eventually went to a Sqlwindows in order to get away from having to worry about the front widget implementations. This meant that we could actually concentrate on building the systems at hand. I should also mention that we did try other 4GL's as well and they all led to Martin's point about each 4GL supporting a single application model. Here's some points that I can reflect on as far as the pluses of either methodology: 4GL Pluses: - virtually eliminate time spent on developing the controls - close link to the database - cross platform compatability - some 4GL app's are freely distributable w/ routers; with 3GL's YOU have to buy and supply the middleware. 3GL Pluses: - smaller app sizes - faster apps - more control over app model; assuming you are not using an app generator - control over all aspects of the app ----------------------------------------------------------------------
>From: cdutley_at_iglou.iglou.com (Craig Utley)
>Subject: Re: Acess 2.0 vs Powerbuilder
>Organization: The Internet Gateway of Louisville, KY

>Jeff,
>We have used both Powerbuilder and Access (and Paradox and...). The
>main diff. to our MIS dept is that Power builder seperates the processes
>from the data. A programmer can develop an application in Corvallis and
>connect it to an Informix DB in Palo Alto and install it on a PC in
>Singapore. The executable is an .exe file and the db's can be managed by
>a central organization. Local files can still be under the users control
>and PC. MS-Access is however great for proto-typing an application. The
>structures and SQL queries can be tested without extensive MIS envolvment.
>But, like any proto-type, it will be thrown away later.
>I do support some MS-Access db's but MIS and the user dept. must work M
>in a partnership; NOT as a "job shop" or contract basis.
>I see Powerbuilder beeing used more and more here at HP in Corvallis.
------------ Sorry to hear that. We have been through a simialr phase, and I can say that Powerbuilder has only two advantages over Access: 1) Compiles to an EXE 2) Check-in/check-out of objects Other than that, I have found Powerbuilder horrible. I could go on forever about the lousy interface, bad data controls, etc. But try to dial in via SLIP and hit an Oracle/Sybase/etc and Watcom at the same time. Nope. Technically it is possible, but typically it chokes. Access is not just a prototyping tool. Done correctly, it is data-independent, distributable, and everything else you would want. We have one app with over 500 users around the country dialing into an Oracle 7 database via SLIP and SQL*NET with no problems. And 2.0's pass-through queries are great for that! We have one app with 70 simultaneous users hitting an Oracle back-end that has about 8 gigs of data. All in all, we have found Access handles everything Powerbuilder wishes it could do. I honestly do not see why ANYONE would EVER choose Powerbuilder. Not just when compared to Access, but EVER. I think some people think that just because it costs $3,000 it must be better. I know Powerbuilder has a big following, but I do not understand it. Just my opinion. No one get too carried away. ----------------------------------------------------------------------
>From: emmetj_at_PROBLEM_WITH_INEWS_GATEWAY_FILE (Emmet_Jones)
>Subject: Re: Acess 2.0 vs Powerbuilder
Jeffery Thomas (jdthomas_at_nyx10.cs.du.edu) wrote: : : My organization is trying to decide between Powerbuilder or : Access 2.0 as the client tool in a client/server app. We've been : developing with Access 1.1 but were on the verge of switching to P : Powerbuilder when we found out that Access 2.0 was being released. : It's imperative that the front-end tool provides a sqlpassthru : capability that will allow us to utilize all of Oracle Server 7 : features (packages, stored procedures, sequences, sql keywords : such as NEXTVAL/CURRVAL pseudcoumsn, CONNECT, etc). : : Will Access 2.0 provide such a capability? : : Jeff Thomas : Jeff, We have used both Powerbuilder and Access (and Paradox and...). The main diff. to our MIS dept is that Power builder seperates the processes from the data. A programmer can develop an application in Corvallis and connect it to an Informix DB in Palo Alto and install it on a PC in Singapore. The executable is an .exe file and the db's can be managed by a central organization. Local files can still be under the users control and PC. MS-Access is however great for proto-typing an application. The structures and SQL queries can be tested without extensive MIS envolvment. But, like any proto-type, it will be thrown away later. I do support some MS-Access db's but MIS and the user dept. must work in a partnership; NOT as a "job shop" or contract basis. I see Powerbuilder beeing used more and more here at HP in Corvallis. ----------------------------------------------------------------------
>From: sli_at_crash.cts.com (David Randolph - Shared Logic Inc.)
>Subject: Re: VISUAL BASIC vs POWERBUILDER
Chan Hoong Keong (hkchan_at_hkchan.pc.my) wrote: : In article <CpCLGv.M93_at_crash.cts.com> sli_at_crash.cts.com writes: : > PowerBuilder support for VBX is limited to version 1.0 and is so buggy it : > is unusable. It also doesn't support OLE 2. : > : I have been wondering about the VBX support in PowerBuilder. Look like : you are right about the bugginess. As for OLE 2, it is still at its : infancy and the market is just about to respond to it. Still, Microsoft : compilers will always be a better choice if it is definitely necessary to : put all the new features into existing products right away. For some : though, this is not a prime considerations. : > To say that PowerBuilder's only shortcoming is its price is a prime : > example of tunnel vision. PB has a lot of nice features, but it has many : > disadvantages compared to VB. The DataWindow, while powerful, uses a : > non-standard Windows UI. The resulting application is unmistakably a : > "Powerbuilder App" and is easily distinguishable from a "Windows App." : > This is often an acceptable compromise for most developers, so I can : > understand why many would choose PB for development. : VB does produce more Windows-like applications. But we can still spot a : VB applications easily by its radio buttons and check boxes. As far as : Windows controls go, both PowerBuilder and VB has their in and out, and : I guess they are even on this term. What makes PowerBuilder really : better is the OOP feature as well as datawindow. They make database : applications development so much easier. However, VB seems to be better : for the job to develop multimedia and other Windows applications. : Because PowerBuilder is slower in script execution, and does not come : with a wide range of custom controls that covers every aspect in Windows : API. Since I have on occasion used VB as a prototyping tool for my C++ applications, I can assure you that I can create VB apps that are completely indistinquishable from C++. In these occasions, I flip back and forth between the VB form and Resource Workshop (or AppStudio) so that not ONE pixel is different. BTW, repaint speeds are very comparable for identical forms, assuming ClipControls=False. : > For developers that strictly adhere to the established Windows standards, : > Visual Basic is a far better environment than PB. : > : If the developers do not wish to compromise at all, C++ is the only : environment to go. Ah, there is alway compromise, just for different issues. :-). With C++ and Visual Basic it is the productivity of the development environment and tools. In many situations a combined approach provides significant benefits. This is where the importance of using consistent UI design becomes important. The user shouldn't be able to tell what tools were used, only that everything "works right" and looks consistent. For a commercial retail product, the only real choice has been C and C++. ----------------------------------------------------------------------
>From: sli_at_crash.cts.com (David Randolph - Shared Logic Inc.)
>Subject: Re: VISUAL BASIC vs POWERBUILDER
Gunther Birznieks (birzniek_at_nova.umd.edu) wrote: : In <CpCLGv.M93_at_crash.cts.com> sli_at_crash.cts.com (David Randolph - Shared Logic Inc.) writes: : >To say that PowerBuilder's only shortcoming is its price is a prime : >example of tunnel vision. PB has a lot of nice features, but it has many : >disadvantages compared to VB. The DataWindow, while powerful, uses a : >non-standard Windows UI. The resulting application is unmistakably a : >"Powerbuilder App" and is easily distinguishable from a "Windows App." : >This is often an acceptable compromise for most developers, so I can : >understand why many would choose PB for development. : >For developers that strictly adhere to the established Windows standards, : >Visual Basic is a far better environment than PB. : >I do hope that many of the features in PB appear in the next version of : >VB, and visa versa. : How is the datawindow make the PB application "nonstandard" with : respect to the GUI? The Datawindow essentially groups all the fields : in a logical place on the window. I always understood that GUI : Interface design consisted of making windows that contain controls in : logical grouping. :). One obvious difference is the funky Character Mode style shading, no Windows style 3d effects (CTL3D.DLL), as well as many other "unique" attributes. Again, this isn't necessarily bad unless you are trying to adhere to a strict Windows app look and feel. : As a sidenote, the datawindow is actually one of the better examples : of how PowerBuilder is even more efficient and technically better than : VB. Because the fields of a query are grouped on a datawindow control : instead of individual fields, you have a great advantage in that at : any given point for a Window with 1 datawindow control in : PowerBuilder, you will have only a couple handles of resources taken : up in the limited GDI and Kernal stack of 16bit windows. This is : because the Datawindow is 1 control plus an edit control for whichever : field on the datawindow control has focus. Fields that do not have : focus are not actually seperate controls. (I believe that is why the : messages operate the way they do for a data window). Thus, even if : you have something outrageous like 20 fields on a form in : PowerBuilder, you still take up the same efficient 2-3 handles that it : would if you had 2 fields on the form! I'm very aware of the resource limits, but this is managable for a careful developer. PdoxWin uses the same approach as Powerbuilder in this respect, and it is its biggest problem in my book. Windows users expect controls to behave and look consistently. This is not to say that a program can't use new controls, so long as any existing UI standards are accomodated in a manner that most users will consider acceptable, GIVEN that they often use many other Windows apps too. Consistency across Windows apps is the most difficult task because there are no UI Police, but has the greatest importance for interoperability. Using non-Windows controls also eliminates the ability to use the Windows SDK functions, greatly limiting extensibility and significantly increasing the amount of code needed to many simple things (like redirecting keys to a Combobox for an incremental key search algorythm). Dropping down to the SDK is critical in some situations to get the desired UI behavior. Using the resource limit as a fundamental decision for UI design is short sighted given that this (very real) limitation is soon to be lifted with the release of Chicago. -- Dave R. ---------------------------------------------------------------------- ###################################################################### Secion 6 - How to evaluate ----------------------------------------------------------------------
>From: gowen_at_sevmsa.cs.msstate.edu
Below is the summary of replies that I received in response to the following message, which I posted to the SE newsgroup. If you have any questions or concerns, please contact me. Original Message
>I am looking for references to techniques/methods for evaluating software
>tools. For example, the 1st ACM SIGSOFT Software Engineering Symposium
>(held in June '81) focused on evaluating software tools and methodologies.
>Of particular interest to me are references that focus on the following two
>items: (1) developing criteria to evaluate a tool or tool set with respect
>to a specific environment and (2) deriving numerical values with respect to
>these criteria for a specific tool.
>
>I would greatly appreciate any references to such methods that you may know.
>If anyone shows interest in the results of this query, then I will post a
>summary of the literature that I receive. Please send all responses to my
>e-mail address instead of wasting bandwidth on this newsgroup.
Lon -- Lon D. Gowen, Ph.D.; Office: (601) 323-2756; Fax: (601) 325-8997 e-mail: gowen_at_cs.msstate.edu US Mail: Computer Science Department; Mississippi State University; Butler Hall Room #320; P.O. Drawer CS; MS State, MS 39762 **************************************************************************** Date: Wed, 20 Apr 94 14:45:45 CDT From: carter_at_CS.MsState.Edu Rowley. Selection and evaluation of software. Aslib Proceedings 3/1/1993 Adeli and Wilcoski. A methodology for the evaluation of structural design software. Computers and Structures v49,n5,1993 Williams. Approisal and evaluation of software products. Journal of Information Science v18,n2,1992 Martin. Evaluation methods of standard software with respect to their effectiveness. Intern. J. of Production Economics v24,n3,1991 or 1992 Rushinek. A product evaluation and selection system for project management software. Computes in Industry v16,n3,1991 Krupp. Strategic issues in software evaluation for manufacturing firms. Production and Inventory Mgmt J. v.32,n1,1991 Anderson. Choice models for the evaluation and selection of \ software packages. Journal of Management Information Sys. v6,n4,1990 Smaldino. A science software evaluation matrix. The Journal of Computers in Math and Science v8,n4,1989 Anderson. A heuristic for software evaluation and selection. Software Practice and Experience v19,n8,1989 Arditi and Singh. Selection criteria for commercially available software in construction accounting Intern. Journal of Project Management v9,n1, 1991 Midyett. Industrial software: Application software selection. Chiltons I&CS v63,n11,1990 Kilmer. Software selection for aerospace and defense industry manufacturers. P&IM Review and APICS News v10,n2,1990 **************************************************************************** Date: Thu, 21 Apr 1994 17:03:42 -0600 From: dwe_at_eng.iac.honeywell.com I don't have anything formal to refer you to, but I have found the following to work for me (particularly #9 below): 1) solicit/determine requirements for want you need. a) These should be short (one line or so) concrete statements b) Each must be able to be measured in some way for compliance (eg: "easy to use" is subjective, if your organization can do it, have them define "easy": has a GUI, uses menues, has selection lists, is in color, etc.) c) Get all the req's. ... better to have too many one liners than leave out something crucial. d) arrange the requirements in groupings so you can get related "roll- up" categories ... i.e., put all user interface req's together, all integration issues together, all platform issues, support issues, etc. e) number each reequirement for easier cross reference later. 2) determine the relative importance of each req'. a) devise some scale meaningful to your organization and set priorities. I like a 0-5 scale, with 5 being "required-critical" and 0 being "didn't need it after all" b) assign a priority to each requirement. 3) devise a compliance scale with meaning for your company. o I like a 0-10 scale, with 10 being "exceeded my wildest dreams", 9 being "fully met req't", 8-6 = "met in varying degrees", 5-2 = "didn't meet in varying degrees (like how hard would it be to make it meet it), 1 = "failed to meet", and 0 = "doesn't, won't, and never will" o Others like a -2 to +2 scale with 0=fully meets, -2=fails, +2=exceeds. 4) have several team members try/test/use/read about the tool independently and assign your appropriate compliance rating value to each requirement. (tell them a skipped item will be assumed to be "0" or something to cover yourself, but see below to find out how I really handle this.) 5) If it's vendor-supplied tools, mail your requirements to them and ask for a self-rating. These are often totally useless 'cause you'll get lots of 10's, but that tells you something about that vendor's integrity, too. (particularly if you sandbag it with some requirement you know can't be met and watch for the 10's). These *do* provide good "sanity checks" on your evaluation (if you gave it 9 and they gave themselves 1 or reverse) and some humor too. (I leave vendor empty responses as a "0".) 6) make up a spreadsheet to easier tally the results. a) provide the req' number and a short description. b) include the priority value c) provide a switch in your spreadsheet so you can compute "raw" or "priority weighted" totals. d) enter each responder's raw compliance value e) At this point, I try to come up with a "composite" of the user responses for each tool (the vendor response stands alone). But you usually can't just average the responses ... some give 9 for partially meets, some 6 ... you'll need to see how bad it is and come up with a way of "normalizing" the responses to each other ... then you can combine them so if some responders didn't give answers on some req's but others did, you end up with a proper "combined" result" f) at the "roll-up" point, add all the sub-req's together for "raw" or multiply each by its priority, then add them for "weighted". g) If you insist, add up each "roll-up" to get a fiinal "total" (This is dangerous ... you really need to look at more than just a total to decide and managers probably want a go/no go answer. e.g., a good total that missed all your criticals but was outstanding on the req's you cared little about isn't as good as one that barely met all your criticals and flubbed on the rest.) h) Be certain to analyze each response against "critical" requirements to ensure nothing is missing. 7) Solicit input from other users (either vendor ref's or internet info.) 8) determine a way to consider price, cost (price + local issues), maintenance and support, results of responses from internet and other companies... at least summarize these in your report. 9) Be prepared to use some manager's favorite tool anyway, no matter what the evaluation says. ;-) Good luck, -- +----------------------------------+----------------------------------+ |Dave Eaton | e-mail: dwe_at_eng.iac.honeywell.com| |Honeywell Inc. - IAC | FAX: (602)789-4064 | |16404 N Black Canyon Highway | voice: (602)863-5094 | |Phoenix, AZ 85023 | HED: AZ15/2E8 | +----------------------------------+----------------------------------+ **************************************************************************** Date: Thu, 21 Apr 94 09:01:51 EDT From: Patricia Oberndorf <po_at_SEI.CMU.EDU> The DoD is quite interested in this topic and has done several things. Most recently we have started a working group, under the leadership of Bob Hanrahan of the Air Force (hanrahar_at_wpo.hill.af.mil), to consolidate the results of work done separately by the Army, Navy and Air Force. (Each is a report listing numerous criteria to be used in evaluating tools and environments.) In addition, we have started to address the issue here at the SEI; see the paper we gave in the Environments track at STC, held last week in Salt Lake City - Bob can also get that for you (authors: Brown, Carney, and Oberndorf). There is also work that has been done at the ISO level; you can contact Barbara Cuthill (bcuthill_at_swe.ncsl.nist.gov) for more information on that - it gives more an overall approach than specific criteria, as does an environment evaluation and assessment report that Barbara has written recently. Hope this helps! Tricia Oberndorf **************************************************************************** Date: Thu, 21 Apr 94 15:05:44 EDT From: Barbara Cuthill <bcuthill_at_sst.ncsl.nist.gov> Tom Vollman (vollman_t_at_vaxa.smcm.edu) chaired an IEEE committee which last year completed a Recommended Practice for CASE Tool Evaluation and Selection (IEEE 1209). This work has been taken into ISO in committee JTC1/SC7/WG4 and is being worked for an ISO technical report to be published next year. 1209 and the ISO report include an outline of a methodology and suggested criteria for the evaluation and selection process. There is a followon effort (also chaired by Vollman) to write a Recommended Practice for CASE Tool Adoption (IEEE P1348) which will also eventually be migrated into an ISO technical report. This recommended practice puts the evaluation and selection process puts these processes in the context of the full adoption effort. It addresses the issues of understanding the organization's process BEFORE buying tools, determining if the organization is ready for CASE tools and tranisitioning the tool into the organization. I would suggest contacting Vollman for an up to date draft of the documents in progress and IEEE for a copy of 1209. The Software Technology Support Center at Hill AFB puts out a number of reports each year evaluating CASE tools in specific domains. These reports do include lists of criteria and the methodology used in applying them. Bob Hanrahan, who Tricia mentioned, is probably the best contact for this work. I assume by now you have heard about Vicky Mosely's work for Westinghouse in this area, but "How to Assess Tools Efficiently and Quantitatively" IEEE Software, Vol.9, No.3, May, 1992. is a good article. Other articles in the same issue are "Assessing Testing Tools in Research and Education" by Joseph R. Horgan and Aditya P. Mathur and "Evaluating and Selecting Testing Tools" by Robert Poston and Michael Sexton. The entire issue focused on CASE tool issues. I'll send you a copy of the report I did for NIST last year. Primarily, this looked at a possible methodology for evaluating software engineering environments and pointed to other sources for criteria, primarily 1209 and STSC documents. I'm very interested in the results of your query. Please, let me know what you collect. Barbara Cuthill NIST **************************************************************************** Date: Mon, 25 Apr 94 10:34:41 PDT From: lowell_at_tc.fluke.COM (Lowell Skoog) I would be interested in seeing a summary of your results. I don't have references to literature on evaluating tools, but I have some practical experience of tool evaluation in a medium size organization. My experience is that the success or failure of a tool is often less dependent on the quality of the tool itself, or even on the completeness of the selection criteria, as on how well the users of the tool "buy-in" to the selection process. Tool deployment is a form of organizational change and must be managed as such. --- Lowell Skoog Fluke Corporation Everett, WA, USA lowell_at_tc.fluke.COM {uunet,microsoft}!fluke!lowell (206) 356-5283 **************************************************************************** ###################################################################### End of File ######################################################################
Received on Sat Jun 25 1994 - 05:19:08 CEST

Original text of this message