GuptaPro - Jeff Luther/PC Design · •Centura Report Builder •Centura Ranger Centura Builder Centura Builder is the new, integrated development environment, akin to the SQLWindows

ProHot Ideas for Gupta® (and Centura!) Developers

Gupta

1 Centura ExploredR.J. David Burke andDavid Holmes-Kinsella

2 Nice Work, If YouCan Get ItMark Hunter

8 Function Callsvs. MessagingWalter Wantman

12 5 Stupid Batch TricksRick Greenwald

14 Experts DivulgeTheir Secrets!Doug Mitchell

March 1996Volume 1, Number 2

Continues on page 3

TM

Centura ExploredR. J. David Burke and David Holmes-Kinsella

Recently, Gupta Corp. formally

announced its new Centura

product line. This article—written

by two Gupta consultants—

provides an overview, additional

details on what Gupta (soon to be

Centura Software Corp.) talked

about, and insights for you on

migrating from SQLWindows and

SQLBase.

products that enable developers to build next generation client/serverapplications. The family includes:

• Centura Team Developer• Centura Ranger• Centura Web Data Publisher• Centura Application Server

These products are (and will be) the result of an engineering effortinitiated over a year ago to provide an architecture for developing nextgeneration client/server applications. While the first generation of client/server tools focused on ease-of-use and proof-of-concept, next generation toolsinclude features for managing enterprise-level development and deployment,scalability, integration of disparate data sources, and replication.

This overview is based on pre-release information. It’s possible thatproduct configurations, capabilities and availability may change by the timeyou read this, but this information was accurate at the time of writing. Futurearticles in Gupta Pro will delve into the new features and capabilities

Scale upCritics of first-generation client/server tools often point to the inability ofthese tools to scale up beyond department and work-group level applications.

The Centura product line isbeing launched with threethemes: Scale Up, Reach Out,

and Connect It All. Behind eachtheme you’ll find significant newfeatures and products that enablethe development of next-generationclient/server applications. In thisarticle, you’ll find a quick overviewof each theme, along with detailedproduct information.

First, back to the beginning.Centura describes the new family of

ProG u p t a

Editor Mark Hunter, Publisher Dian Schaffhauser, Department of Distraction Casey and Kelly

Gupta Pro is published monthly (12 times per year) by ProPublishing, PO Box 18288, Seattle, WA 98118–0288.

POSTMASTER: Send address changes to Gupta Pro, PO Box18288, Seattle, WA 98118–0288.

Copyright © 1996 by Pro Publishing. All rights reserved. Nopart of this periodical may be used or reproduced in anyfashion whatsoever (except in the case of brief quotationsembodied in critical articles and reviews) without the priorwritten consent of Pro Publishing. Printed in the United Statesof America.

Gupta Pro is a trademark of Pro Publishing. Other brand andproduct names are trademarks or registered trademarks oftheir respective holders.

This publication is intended as a general guide. It covers ahighly technical and complex subject and should not be usedfor making decisions concerning specific products orapplications. This publication is sold as is, without warranty ofany kind, either express or implied, respecting the contents ofthis publication, including but not limited to implied

Editorial Command Post818-249-1364

Subscription Headquarters818-249-1364

[email protected]

Fax206-760-9026

MailPro PublishingPO Box 18288

Seattle, WA 98118-0288

Source Code on CompuServeGO GUPTA, Library 10

warranties for the publication,performance, quality, merchantability,or fitness for any particular purpose. Pro Publishing, shall notbe liable to the purchaser or any other person or entity withrespect to any liability, loss, or damage caused or alleged to becaused directly or indirectly by this publication. Articlespublished in Gupta Pro reflect the views of their authors; theymay or may not reflect the view of Pro Publishing. Opinionsexpressed by Gupta/Centura Software employees are theirown and do not necessarily reflect the views of the company.

Subscription information: To order, call Pro Publishing at206-722-0406. Cost of domestic subscriptions: 12 issues, $129;24 issues, $199. Canada: 12 issues, $144; 24 issues, $229.Outside North America: 12 issues, $159; 24 issues, $259.Individual issues cost $12 ($15 outside the U.S.).All funds must be in U.S. currency.

Gupta technical support: Call Gupta Corp. at 415-321-4484.

If you have questions, ideas, spud gun targets, or would justlove to chat about what you’re doing with Gupta products,contact us via one of the means at right.

Give Us a Jingle!

2 Gupta Pro March 1996

Nice Work, If You Can Get ItMark Hunter

incident) has been discontinued. The least expensive wayto talk to a Centura support person now is Silver LevelTechnical Support: $6,000 per year, with two-business-dayresponse time. It’s even more expensive to do businesswith Centura Software internationally. The $5,000 cost ofCentura in the U.S. rises to 12,000 marks in Germany,which far exceeds the exchange rate adjustment.

But why quibble so much about the cost of theproduct? Companies are paying talented developers$50,000 to $100,000 or more per year to produce largeclient/server applications. Viewed in this context, theprice increases associated with Centura are insignificant ifthe product offers even marginally better productivity.Large enterprises spend huge amounts of money onrecruitment, training, and continuing education of theirdevelopers to increase productivity; buying an increasethat comes out of a Centura box is cheaper than any of theother methods.

It’s the smaller customers and developers who arehurt by the recent changes. There are quite a few shopsout there that have been loyal Gupta customers for years,and have built good, solid applications that run onSQLBase servers and small networks. Gupta productsalready strained their budgets; they may have trouble

As Gupta Corp. reinvents itself, some developershave become increasingly worried about thetarget market that Centura Software Corp. will

pursue. Gone are the days when SQLWindows battledhead-to-head with PowerBuilder for the same customers.Centura will be pitched to large, sophisticated enterprisesfor whom PowerBuilder, and perhaps even SQLWindows,are not sufficiently productive and powerful. The generalidea at Centura Software is to paint Centura as a moreopen, less expensive sibling of tools like Forté, whichcosts about $10,000 per seat. Some of this change inmarketing has been instigated by Gupta’s BusinessPartners, who actually encouraged the company to raiseprices, not lower them, in an effort to distinguish Centurafrom the rest of the field and communicate its greatervalue as a development tool.

Centura Team Developer will cost about $5,000 percopy when released. The other Centura components(Ranger, Web Publisher, Application Server) will beexpensive, too. The LMS subscription plan, whichpreviously guaranteed U.S. subscribers deep discounts onmajor releases, will no longer do so (after the currentoffering of $995 for LMS customers to upgrade toCentura)—only minor releases will be included. The Pay-Per-Incident telephone support offering ($175 per

Continues on page 11

Gupta Pro March 1996 3

The idea behind the new Centura Team Developer is toenable you to incorporate three-tier (and beyond)architecture, manage corporate development teams, andproduce fast executable code. A new user interfaceprovides an intuitive and productive work environment.The Centura Application Server (scheduled for Q3)enables you to partition SAL code for multi-tieredapplications, eliminating the need for multipledevelopment environments.

Reach outThe momentum behind the Internet is affecting manyother areas of our industry. For example, word processorsare now being bundled with web browsers and HTMLviewers. And many companies are developing internalnetworks—intranets—for accessing and manipulatingcorporate data. The Centura family of products integratesInternet-related technologies with client/serverapplication development. Centura Team Developer willinclude Internet QuickObjects, to let you provide HTMLbrowsers and FTP capabilities in applications. TheCentura Web Data Publisher provides a securemechanism for heterogeneous replication, enabling theuse of web browsers to view corporate data.

Connect it allCentura Ranger enables decentralized heterogeneousreplication for mobile and occasionally-connected users.And the Centura Ranger functionality can be embeddedas an OCX control into applications developed with anOLE-compliant tool, including, of course, Centura TeamDeveloper.

What’s there?

Centura Team DeveloperCentura Team Developer is the new flagship product.Like SQLWindows, Team Developer is a comprehensiveapplication development environment. It consists ofvarious tools that have their roots in the SQLWindowsproduct line. Team Developer includes:

• Centura Builder• Centura Object Compiler• Centura Team Object Manager and Centura Team

Object Repository• Centura Report Builder• Centura Ranger

Centura BuilderCentura Builder is the new, integrated developmentenvironment, akin to the SQLWindows Designer. Familiar

features like the visual design tools are still present, butthe user interface has a whole new look. Enhancing theExplorer interface from Windows 95, Centura Builderadds a tabbed-list on the right hand side of the Explorer-style window. The various tabs provide different views ofthe application and its components. Figure 1 shows thenew user interface.

The new interface reveals the slight paradigm shift inapplication development. The component idea is now afoundation concept of the development environment. Forexample, applications are made up of components such asclasses, menus, functions, and windows.

Other new user interface features include dockableand detachable tool bars, context-sensitive popup menus(activated with a right-mouse click), and more wizards tosimplify component development (discussed shortly).

The SAL fourth generation language has been “re-acronymed” to Scaleable Application Language. SAL islargely unchanged in the initial release of TeamDeveloper, but there are some new SAL functions. Theinternal project to enhance SAL with more powerfulprogramming constructs continues and will debut in afuture release of Team Developer.

Also in the works: the licensing of the Java languageand interpreter from JavaSoft (Sun Microsystems, Inc.).This language technology will be incorporated into afuture release of Team Developer as well (scheduled forQ4, 1996). It’s planned that future releases of TeamDeveloper will support the development of Java applets(by converting SAL to Java, which should be fairlystraightforward, since SAL is already being converted toC for the SQLWindows C Compiler interface). The use ofthe Java interpreter opens the door to other possibilities,such as executing SAL code (through the Java interpreter)on other platforms (see the discussion on CenturaApplication Server).

Centura Explored . . .Continued from page 1

Figure 1. Centura Builder sports a new userinterface, built on Windows 95’s Explorer interface.


The native code compilation (Centura ObjectCompiler) facilities are now integrated into thedevelopment environment as well. Also, the long awaitedDynalibs feature is now available. In case you’reunfamiliar with them, Dynalibs are like File Includes; butthe file is compiled like an executable before beingintegrated into an application. What are the benefits tothis approach?

• Dynalibs present only the interface of included items.This supports encapsulation and modulardevelopment.

• They have their own data storage, so the memoryrequirement of the main executable is reduced.

• Dynalibs are distributed along with the applicationexecutable. This eases maintenance and upgrades bysending out only the modified Dynalib file instead ofthe whole application.

• Dynalibs shield source code, protecting theinvestment of class library developers.

Some of the most exciting new features in TeamDeveloper include support for three-tiered (and beyond)application development. Team Developer includes aremarkable Three-Tier Wizard that really simplifies theconstruction of three-tiered applications. Using the Three-Tier Wizard, you start by selecting a distributedenvironment. The initial release supports Novell’sTuxedo, DCE RPC, and IBM’s CICS. Further dialogsappear to get more details about the distributed services.Then a functional class is created in the application thatprovides an interface to the distributed services.

Centura Application Server (scheduled for Q3) willexecute SAL code on distributed servers, enabling

developers to create partitioned applications with onetool. Like SQLWindows, Centura Team Developer willalso be ported to the Solaris environment. This enables theexecution of performance-intensive and mission-criticalcode on a server-class platform, using CenturaApplication Server.

Centura Team Object ManagerTeamWindows has evolved into Centura Team ObjectManager. The new user interface, the enhanced Explorer-style window, is used here as well to present therepository objects. But many other new features makeTeam Object Manager much more compelling to use aswell—even in a single developer/single projectenvironment.

Team Object Manager now allows simultaneouscheck-out of a Centura Builder file. The changes aremerged when the file is checked back in. Conflictmanagement is also included. For example, say you andanother developer check out the same file and work on itat the same time. What happens when you both check itback in? TOM has merge features whereby it analyzesyour code and figures out how to integrate the changes.Of course, if you’ve both worked on the same function,then TOM is going to throw up its hands in horror—atthis point it will leave the old code intact and show youthe alternate versions of the new code, commented out.(Not that this is a bad thing... Who in their right mindwould assign two developers to work on the samefunction—assuming that function is smaller than a fewthousand lines!)

Team Object Manager also supports configurablepromotion levels, build files (with a Build Wizard),project-level configurable security, log management, andproject branching.

Another major new feature is the integration of anEntity-Relationship diagramming tool that supports theIDEF1X modeling method and notation. This toolprovides many of the features found in high-endmodeling and diagramming software.

Finally, Team Object Manager also includes a ClassBrowser, which graphically depicts classes and theirinheritance hierarchies. This tool can also be usedindependent of Team Object Manager, as a standaloneutility. Figure 2 shows a portion of the QuickObject classhierarchy using this tool.

Centura Web Data PublisherScheduled for a Q2 release, Centura Web Data Publisherprovides a secure way for Web browsers to access datafrom SQL databases. Web Data Publisher converts HTMLcommands into SQL statements that can be issued to adatabase; the returned result set is converted back toHTML. Web Data Publisher provides the interfacebetween a Web server and SQL databases. This

Figure 2. The new Class Browser shows the hierarchyof your classes with a graphical presentation.


technology will enable new approaches to distribution ofdata, especially in corporate environments. ExecutiveInformation Systems will never be the same!

Centura Application ServerCentura Application Server will allow you to takeportions of your code and move it from your clientmachines to middleware running on Windows NT boxes.This promises to be a great boon to developers who arelooking to scale their applications. In the traditional two-tier world, a database might start out as Access orSQLBase/Windows and then be migrated to SQLBase/NetWare. Whenthe user loadgrows too largeor the datarequirementsare sufficientlyhuge, it hasbeen customaryfor people tolook to Sybase,Oracle, and therest of theUNIX/midrangedatabase marketto serve theirpurposes.However, assystems scale into the hundreds or thousands of users, thetwo-tier architecture starts to break down under the loadon the network and the difficulties of deployingmaintenance releases to many differently configuredmachines.

Enter three-tier! It allows the application to besegmented into presentation on the client, business logicin the middleware, and data storage at the back end.When an application’s business logic needs to be changedor a new system needs to come on line and must followdata access rules already prescribed by the businessanalysts, then only the middleware needs to be changed, asignificantly easier job (often by several orders ofmagnitude) than upgrading all the existing client PCs.

The disadvantage of three-tier architecture is that itrequires arcane file definitions, typically generated withutilities such as RPCMAKE, and complicated C languageprogramming—and often demands the programmer toaddress issues such as transaction recovery and messagebuffering or pacing, all of which have been elegantlysolved in the two-tier world and by the vendors of thehigh-end TP monitor software.

The Application Server provides entree into the three-tier world and allows different parts of your applicationsto be deployed (and thus executed) on different machines.

Gupta is in the process of implementing very innovativesolutions to some persistent design issues in this area, notthe least of which is the fact that you can build theseobjects as functional classes and deploy them as Dynalibs.For added speed you’ll simply compile them into C DLLcode! The requirement for C language coding willdisappear. That is good, since typical projects typicallytake much longer to build in C/C++ than in a 4GL likeSQLWindows or a second-generation tool such as CenturaTeam Developer. As Gupta’s plans crystallize, you canlook forward to an in-depth examination of theApplication Server in a forthcoming issue.

Centura RangerReplication, ahot topic in thedatabase world,initially focusedon distributingcorporate dataacross theenterprise.Distributedreplication is asolution forproviding aconsistent viewof data acrossmultipledatabase

servers. However, distributed replication is not suitablefor replicating data to mobile users, whose only access tocorporate data is a dial up connection, or an occasionalconnection to a network. Centura Ranger focuses ondecentralized replication, which addresses the issues ofmobile users.

Using Centura Ranger, mobile workers such as a fieldsales force can use applications that work with a localdatabase containing a subset of the corporate data. Thesynchronization capabilities of Ranger provide a near on-line environment.

Centura Ranger provides graphical tools to managereplication at both the publisher (the corporate server)and the subscriber (the mobile user). Ranger usestechnology that has its origins in SQLConsole. Onceagain, the new Explorer-style interface is used. Thegraphical tools provide for quick and easy setup of thereplication process.

One of Ranger’s architectural strengths will be itssupport for heterogeneous replication. Most productstoday are homogenous, that is, they support replicationbetween the same types of databases. For example, Oracleto Oracle or Sybase to Sybase. Although the initial releaseof Ranger will be for SQLBase-to-SQLBase replication,future releases will take advantage of the architecture for

Centura Schedule for 1996


replication between disparate database brands. Supportfor Oracle is first on the list and other major SQLdatabases will follow.

Is Centura for me?The Centura product line is focused on building nextgeneration client/server applications. Not allorganizations are ready for this type of development, sofirst generation client/server development will still bearound for awhile. A major factor to consider is thatCentura products are designed for 32-bit Windowsenvironments: Windows NT and Windows 95. The 32-bitsubset of functionality, Win32s, is not suitable for Centuraproducts (at least not in its present form).

But if you’ve moved to 32-bit Windows, don’tautomatically assume that you need to switch fromSQLWindows to Centura Team Developer. SQLWindowsis still a fine tool and appropriate for many developmentefforts, especially at the department and workgroup level.Team Developer addresses the needs of enterprise leveldevelopment.

The real criterion for moving to Centura fromSQLWindows is when you’re ready and need to takeadvantage of the new features: three-tier wizards, InternetQuickObjects, more efficient team programming, and theenhanced object compiler to support enterprise leveldevelopment.

The future of SQLWindowsGupta’s announcement also discusses the future ofSQLWindows. SQLWindows will continue to besupported and enhanced for as long as 16-bit Windowsdevelopment is widespread. A new SQLWindowsmaintenance release, code-named Cyclone, is scheduledfor release in Q3. Features planned for Cyclone includeback-porting the object compiler from Centura TeamDeveloper and QuickObjects for building SAPapplications. The SAP QuickObjects will enable thedevelopment of applications that can access SAP’s ABAP/4 application server. This technology, and other similartechnologies like OEC’s QuickRPC, will simplify the useof SQLWindows for three-tiered application development.

For many organizations, concurrent use ofSQLWindows and Centura products will be necessary asthey move to 32-bit development and more sophisticatedapplications. Compatibility between SQLWindows andCentura Team Developer will help ensure a smooth andpainless migration.

Why would I go there?Although there are a host of new widgets lying about inthe user interface, we predict that most companies willmigrate to Centura to take advantage of the 32-bitarchitecture and scalability that it brings.

Even today, customers are looking to move to the

Microsoft 32-bit operating systems to take advantage ofthe substantially greater amount of available resources.Practically gone is the dance of death that we’ve all had tolearn, using GetFreeSystemResources() and processingWM_Create to determine whether we can, in fact, safelycreate a window. At last year’s U.S. Devcon Gupta’s EarlStahl gave a presentation wherein he created anapplication with 2,000-odd objects on the screen. That’snot the sort of thing you can do in the 16-bit versions ofWindows. (Of course, whether you’d ever want to create2,000 data fields at once is an interesting, if academic,consideration!)

However, users running 16-bit applications are stillchained to the miasmic world of Win16. To escape into thebrave new world of 32-bit Windows requires that you run32-bit applications. Once you do that, a host of featuressuddenly becomes available to you. OLE2 technology willbe fully realized on the 32-bit platforms; and it’s whencomponent standards such as OLE or CORBA come intobeing that you can start to build the component-basedarchitectures that have been an elusive target in the past.

How do I get there?From a “cookbook” perspective here are the technicalissues with which you have to concern yourself whenmoving to Centura.

First, SAL code migration. Existing SAL code is fullycompatible with Centura code. What this means is quitesimple: if your application only uses SAL calls and yourdefined messages (SAM_User+1 and higher), and you talkto relational databases via SQLNetwork or ODBC, or useother Gupta-supplied objects such as QuickNotes orQuickMail interfaces, then your code will run unchangedon the Centura platform. (Except of course that it will bebetter, stronger, faster and cure common colds with asingle compile.)

Next, Windows message constants. Some of them (forexample, EM_SETSEL) have changed! You need to ensurethat your constant values haven’t changed. WhyMicrosoft would choose to do this isn’t obvious but it’s upto you to detect and correct the changes.

And, Windows SDK calls. Your (16-bit) SQLWindowsapplications use functions in the 16-bit USER.EXE,GDI.EXE, and KERNEL.EXE, which Microsoftthoughtfully provided. However, your 32-bit Centuraapplications must user the corresponding 32-bit DLLs:USER32.DLL, GDI32.DLL, and KERNEL32.DLL.However, it’s not quite as simple as renaming the LibraryName entry in the External Functions section.

Why not? Well, Microsoft did a couple of things. Forone, they renamed many of the functions as part of theirmove to support Unicode. For example, GetWindowLong(), your friend from 16-bit days is now known asGetWindowLongA( ) and GetWindowLongW( ). Do a hexdump of USER32.DLL to check it out. This problem


doesn’t affect you if you’re writing C/C++ languageapplications as macro definitions in the relevant headerfiles to the translation for you.

So, what to do? Well, you might bite the bullet andrework your external functions to ensure that they call theappropriate functions. The alternative is to make use ofone of the many utilities and include libraries that willturn up in the CompuServe forum (GO GUPTA) or onGupta’s Web site (www.gupta.com andwww.centurasoft.com) or FTP site (ftp.gupta.com).

Hold on; we’re not finished. As well as changingfunction names, some functions have been made obsolete.Others have had their formal parameter declarationschanged. Still others appear to be the same but in truthare not—moving from 16 to 32-bits also has an effect ondata type definitions. Storage types that used to be 16-bitsare now 32! This has a profound impact on any type ofapplication that doesn’t compile with the MS Windowsinclude files. [For a further discussion of this, check out thechapter on “External Functions and Dynamic Link Libraries”in David Holmes-Kinsella’s book, Special Edition: UsingGupta SQLWindows (Que, ISBN 0-7897-0189-8).—Ed.]

But wait, there’s more. You also have to worry aboutyour own DLLs. They’re 16-bit now, right? Of course, theyare; you use them with 16-bit SQLWindows. For Centura,they have to be 32-bit. Do you have the source code? Doyou understand it? Oh dear...

Last, there’s the issue of connectivity. Centura’s nativeconnectivity via the SQL/API has, of course, beenextended to 32-bits. Centura’s connectivity to otherdatabases depends on the vendor supplying (usable) 32-bit client software—SQL*Net, DB-Lib/CT-Lib, IngresNet,ODBC, and the rest. Gupta’s ability to provide databaseconnectivity will be limited by the stability andavailability of the connectivity software from these othervendors. We’ve all experienced “dislocations” in the past(in other words, hair-loss situations) involving stabilityand resource issues under the Win3.x environment. What

lies in store for you will only reveal itself throughexperience.

It’s that simple?Here are a few things that you’ll have to leave behind:

• First, there’s your 16-bit custom controls, be theyVBXs or DLL controls. Do you have replacements inthe 32-bit world?

• SAL code is completely forward migratable—you canmove your code from SAL to Centura withoutproblem. However, moving it back the other way isn’tpossible. This means when you build for Centura,you definitely build for the 32-bit world and not amix of 16-, 24- and 32-bits.

• Any DLLs you have that perform custom processingmust either be migrated to 32-bits or discarded.

ConclusionCentura offers developers tremendous power, flexibilityand productivity. You may be one of the developers whobegin using it immediately to produce very largeapplications. You may wait to migrate your SQLWindowsapplications to Centura when you just can’t do withoutone or more of the new features. And you may decide tohold off until your end users are comfortable moving to32-bit operating systems. In this mix of requirements,Centura and SQLWindows can be expected to coexist for along time to come. P

David Burke is a Senior Consultant with Gupta Professional Services.

CompuServe 102336,171.

David Holmes-Kinsella(“DHK”) is a Senior Consultant with Gupta

Professional Services. He’s a keen cricketer and cites Terry Pratchett

as his chief writing influence. CompuServe 73764,3034, Internet

[email protected].

How can you get your own

official Archie McPhee Spud

Gun? Submit a tip to Gupta Pro

and if we publish it, we’ll send

you the Spud Gun, plus

20 bucks! See page 2 for

e-mail, fax, and address info!

POW! Right in the GPF!

ProG u p t a

Function Calls vs. MessagingThe Differences May Surprise You . . .

Walter Wantman

A lot of myths and fables are active

in this world of ours, and

SQLWindows has its share. This

article brings welcome objectivity

to one of the most frequently-

debated issues: whether it’s more

efficient to use messages, late-

bound functions, or early-bound

functions when communicating

between objects. The numbers

shown here will allow you to make

a rational decision—and you’ll see

that efficiency isn’t the only

criterion.

types and quantities) as well as the impact of hierarchydepth. This article addresses these questions.

Summary of findingsFor those of you who like to read the last page of amystery book first, here’s a summary of what I’ve found(from the obvious to the obscure):

• Early bound functions are faster to execute than latebound functions.

• Receive string functions are faster than regular (non-receive) string functions.

• Receive numeric functions are faster than receivestring functions.

• Regular numeric functions are faster than receivenumeric functions.

• Numeric parameters (Boolean, number, handle, anddate/time) perform the same.

• Increasing the number of parameters degradesperformance in linear amounts.

• Increasing the number of stringparameters degradesperformance faster thanincreasing the same number ofnumeric parameters.

• Early bound functions withseven or fewer numericparameters are faster than amessage call.

• Early bound functions with fouror fewer receive stringparameters are faster than amessage call.

• Early bound functions with threeor fewer regular string parameters are faster than amessage call.

• Late bound functions with seven or fewer regularnumeric parameters are faster than a message call.

• Late bound functions with six or fewer receivenumeric parameters are faster than a message call.

• Late bound functions with three or fewer receivestring parameters are faster than a message call.

• Late bound functions with two or fewer regular stringparameters are faster than a message call.

• Performance of late bound function calls is the sameregardless of class hierarchy depth.

Conclusions and recommendationsHow should these findings affect your programmingstyles and practices? Since you now know that messagecalls generally take longer to execute than function calls,you should try to use function calls whenever practical.However, there are times when a message call ispreferable to a function call, such as:

Since the release ofSQLWindows 4.0 developershave questioned whether it’s

more efficient to use function calls orto send messages. In trying to answerthis question, I did some analysis forthe 1995 Gupta Devcon, where Isimply measured the differencebetween both early and late boundfunction calls (without anyparameters nor depth of hierarchy)and compared them with messagecalls. While these tests showed that ittook longer to send a message than tomake either the early or late boundcall, it left unaddressed the questionsof the impact of parameters (both



• When creating a set of classes that must behave as aself contained object. It would be best to initiate theobject’s behavior by sending it a message; but oncewithin the object try to use function calls to get thebest performance.

• When you need to initiate actions in multiple objects(such as when using messages likeSalSendMsgToChildren).

• In order to be consistent with the paradigm of event-driven programming (where each object contains itsown behavior).

• When there is a possibility of runtime errors (calling alate-bound class-qualified function against an objectthat isn’t a member of that class). A message sent toan object that has no actions for that message will beignored with no error. An incorrect late-bound callwill crash the application.

It’s important to keep in mind that while thedifference in performance time between the calling of afunction and the sending of a message is only about 1/2millisecond, all these calls add up and can therefore havea sizable and noticeable impact on an application’s overallperformance.

performance of function calls.Next, I’ll discuss the various function calls and how

they compare against the message call timing. Please referto the charts labeled: “Early Bound Functions byParameter” and “Late Bound Functions by Parameter.”

Early bound functions

Non-string regular functions

These functions (ones with Boolean, date/time, handle,and number parameters) consistently took the leastamount of time. As the number of parameters increased,the time it took to execute the function also increased inlinear fashion (an average of .113 milliseconds peradditional parameter). Zero parameters took less than athird of the time of a message call (.50 milliseconds), twoparameters took about half the time (.74 milliseconds),and I projected that it would take about nine parametersbefore these functions would take as long as a messagecall.

Non-string receive functions

These functions were also grouped together and asparameters were added, each parameter took anadditional .145 milliseconds (average). While the time ittook to execute a function with one parameter was almostthe same for both the early bound non-string receive and

MessagesOver thenumerousiterations of therunning of thetest, the averagetime it took tosend and returnfrom a messagewas 1.55milliseconds.Since messagecalls aren’taffected byeither thenumber or typeof parameters(they alwayshave twonumeric:wParam andlParam), I’ll usethemeasurement ofthe message callas a baseline forcomparing the


regular functions, as each additional parameter is added,the receive functions took an increasingly longer period oftime to execute. These functions with seven parameterstook about the same time as a message call.

String receive functions

The next distinct line of performance was the receivestring functions. As the number of parameters wasincreased, each additional parameter took on average anadditional .231 milliseconds per parameter. Using fourparameters took just a little less time than a message call.

String regular functions

The last of the early bound function groups was theregular string functions. As parameters were added, theperformance degradation happened in a linear manner ata rate of .316 milliseconds. These functions with onlythree parameters took longer than a message call.

Late bound functionsThe second major group are the late bound functions,which as a group took longer than the early boundfunctions. But within the late bound group, the minorgroup followed the same pattern as the early bound calls.

Non-string regular functions

These functions (ones with Boolean, date/time, handle,

and number parameters) consistently took the leastamount of time among the late bound calls. As thenumber of parameters increased, the time it took toexecute the function also increased in a linear fashion (anaverage of .128 milliseconds per additional parameter).These function calls with seven parameters took about thesame amount of time as a message call.

Non-string receive functions

These functions were also grouped together and asparameters were added, took an additional .152milliseconds (average) per parameter. While the time ittook to execute a function with one parameter was almostthe same for both the early bound receive and regularfunctions, as each additional parameter was added, thereceive functions took an increasingly longer period oftime to execute. These calls with six parameters took alittle longer than a message call.

String receive functions

The next distinct line of performance was the receivestring functions. As the number of parameters wereincreased, each additional parameter took, on average, anadditional .222 milliseconds per parameter. When fourparameters were used, the calls took a little longer than amessage call.

String regular

functions

The last of thelate boundfunction groupswas the regularstring functions.The performancedegradation asparameters wereadded was alsolinear at a rate of.326 milliseconds.These calls withtwo parameterstook about thesame time amessage call.

How thesevariable typescompareIn comparingparameter types,what becomesapparent is thatnon-stringreceive


parameters take a little longer to process than regularnon-string parameters, and regular string parameters takelonger to process than receive string parameters.

I’m not surprised that receive string functions takeless time to process than regular string functions, since thereceive functions only have to pass the value by reference(pointer) while regular functions have to pass the actualvalue.

I don’t know enough about the internals ofSQLWindows to explain why the receive non-stringfunction calls take less time than the receive stringfunction calls, considering that both should be passingpointers (one guess is that it takes longer to locate the nullterminator of the string after the pointer has been passed).Perhaps a knowledgeable reader will be able to explain it.

Does hierarchy depth affect late bound function calls?I wrote a variation on the test program that measured latebound functions calls with class structures with depths ofzero through six levels, inclusive. I then ran severalhundred iterations of the test and tracked the results inSQLBase. I then generated the results and found that theaddition of hierarchy levels HAD NO IMPACT on theperformance (in other words, a late bound string functionwith two parameters took the identical amount of timeregardless of the levels of hierarchy).

How the analysis was doneIn order to determine how long it takes to execute varioustypes of functions, I wrote a set of functions that onlyreturn TRUE. I wrote a function for each type of call to bemeasured, including a function without any parameters,as well as functions that expected from one to sevenBoolean, Date/Time, Window Handle, Number andString parameter types. I wrote a second set of functions

that expected from one to seven receive parameters (of thesame types as previously mentioned). All of thesefunctions were called as both early and late boundfunction calls. In addition, I included a message call thatreturned TRUE when it was received.

To measure the time it takes to execute a function ormessage call, I surrounded each call with a call to thesystem clock and then calculated the difference betweenthe two times. Since the time to execute any single callwould be very short, I made each call 20,000 times (eachcall being made 200 times per loop with 100 loops).

At the end of each loop, the information was saved ina SQLBase database. At the end of the process, averagecall statistics were generated from the database andloaded into Microsoft Excel where the graphs weregenerated.

The timing for the message call is used throughoutthis article as a baseline and appears in the graphs as ahorizontal line. Since messages can only handle twoparameters (wParam and lParam), the same measurementwas compared against the various parameter calls of thefunction calls.

I performed these timings on a stand-alone Gateway2000 486DX/33 PC running MS-DOS 6.2 and MicrosoftWindows 3.1 using SQLWindows version 5.0.1 PTF 2. Thedata was saved in a SQLBase database version 5.2.0a thatwas running on the same PC. P

Download WANTMAN1.ZIP (Go GUPTA, Library 10).

Walter Wantman works for a major financial institution in New York and

has been using SQLWindows since 1990. He received a BFA in Music from

SUNY Purchase and an MS in Computer Science from Pace University.

CompuServe 72260,1713.

justifying the expense of Centura. Software companiesthat used SQLWindows to create packages that runagainst SQLBase must now tell their customers thatsupport will cost a minimum of $6,000 per year; thatwon’t make anyone happy. And it’s less likely that new,small prospects will take on the expense of Centura,regardless of its features. They’ll look at Delphi or VisualBasic or PowerBuilder.

Some of this can’t be helped. Centura Software Corp.can’t be all things to all customers. They say they mustconcentrate their marketing, and especially their saleseffort, on large enterprises that really need all the featuresof Centura. In the past, sales situations whereSQLWindows was thoroughly evaluated against othertools usually resulted in a win for SQLWindows. Now

Centura Software Corp. wants to continue these tactics,but can only afford to do so for the largest prospects. Ifthey’re successful, Centura Software will see profits andgrowth. If not, the low-end users of SQLWindows willdrift away to other tools and Centura will be a nicheproduct for a few hundred large accounts.

It doesn’t make economic sense to use SQLWindowsor Centura in situations where VB or Delphi is goodenough. Centura Software’s new strategy has made thatvery clear, very quickly, to Gupta’s small customers. Nowthose customers must find a new strategy, too. People atCentura feel bad about the recent layoffs there, and theyfeel bad about the increased pressure on their smallcustomers. But the gentrification of Centura is well underway and offers the best hope at present of restoring thefortunes of the company. If the strategy works, Centurawill have large, loyal, and profitable customers. Nicework, if they can get it. P

Nice Work . . .Continued from page 2

ProG u p t a

Five Stupid Batch TricksRick Greenwald

Every once in a while you may find

yourself in need of some old-

fashioned classical batch

processing–moving big chunks of

data into or out of a SQLBase

database server. These tricks can

help you reduce the time batch

processing takes.

fashioned classical batch processing–moving big chunksof data into or out of a SQLBase database server.

This article gives you a few tips on how to increasethe efficiency of these types of write-intensive, non-interactive tasks. Keep in mind that all of these tips willbe effective only with batch-type processing. Not onlywill they not help you out in a typical client/serverapplication, but they may degrade performance or imperildata integrity in normal situations, so only use themwhen they’re appropriate.

Why improve batch processing speed?You may wonder what difference performance makes fora batch job. After all, in a client/server system,performance is generally evaluated by the time it takes forthe system to respond to a user action. And since batchjobs don’t require user interaction, why can’t they justtake however long they take?

Now easy! I’m just posing a rhetorical question toillustrate how client/server systems are built around adifferent performance premise than traditional systems.Performance is always important. It’s true that a definedamount of database writes will require the same amountof some resources, such as disk I/O, but there are waysthat you can reduce the amount of time to complete thetask, or even to eliminate some of the resource usageassociated with the overhead of some database operationsthat may not be required in a batch load situation.

Several years ago, I worked with a large bank inCanada using SQLBase as a LAN-based database to holdinformation that they previously had accessed on amainframe. The plan was to download a subset of the

mainframe data to the SQLBasedatabase every night. Theirdownload was taking in theneighborhood of seven hours. Thiswasn’t too bad. But if the downloadoperation failed near the end,redoing the job would cut into thebank’s working hours. By using someof the tips below, we were able tobring the load down to under half anhour.

Tip no. 1: Try BULK EXECUTEBULK EXECUTE is one of the niftiest ways to improve theperformance of large batch write operations. SQLBaseuses buffers to communicate data and commands over theLAN between the client application and the server. TheINMESSAGE buffer on the client holds data returnedfrom the server, while the OUTMESSAGE buffer holdsSQL statements and bind variables that are sent to theserver. Many SQL statements return fairly large amountsof data, so the results of a single query may span manyINMESSAGE buffers of data. The SQLBase server will tryto completely fill an INMESSAGE buffer with data beforesending it back to the client, to reduce the number of LANpackets that must be sent to deliver the results of a query.Since the information returned to the client usually takesmore than one packet, fewer LAN packets result ingreater information throughput and a more efficient useof the LAN.

The SQL statements and bind variables sent to theSQLBase server by way of the OUTMESSAGE buffergenerally don’t require more than a single buffer. Moreimportantly, you don’t want to delay the transmission of aSQL statement to the server because there was still roomleft in the OUTMESSAGE buffer. SQLBase sends anOUTMESSAGE to the server as soon as the SQL statementis sent to the buffer.

Sending the OUTMESSAGE immediately to theserver is absolutely correct behavior most of the time. Theexception occurs when you send a large amount of data tothe server for UPDATEing or INSERTing. Typically, this isdone with a single SQL statement iteratively executed

SQLBase was designed withmany powerful and uniquefeatures, such as an excellent

optimistic locking strategy andcursor context preservation. Most ofthe time you’ll probably be satisfiedcreating typical client/serverapplications–applications that areread-intensive and interactive. Butevery once in a while you may findyourself in need of some old-



with different values for the bind variables in thestatement. In a situation like this, you could make thetransmission of the data to the server more efficient if youfill the OUTMESSAGE buffer with data the same way thatSQLBase fills the INMESSAGE buffer.

This is exactly what BULK EXECUTE does. If you’redoing your batch job from WinTalk or SQLTalk, you canturn BULK EXECUTE on in SQLTalk by using the command:

SET BULK ON;

The BULK EXECUTE setting only applies to thesession that used the command. Always remember to turnBULK EXECUTE off if you’re continuing to accessSQLBase with the same session, since it could causeanomalies in normal client/server interactions.

If you’re using SQLWindows, you could create abatch file that would run a WinTalk session with theappropriate batch commands.

I’ve personally seen the approach of switching BULKEXECUTE on reduce load time by a factor of eight. If thisis good enough for you, you don’t have to read the rest ofthe article (which would really hurt my feelings but, afterall, it is your life).

Tip no. 2: Increase the OUTMESSAGE buffer sizeUsing BULK EXECUTE to fill the OUTMESSAGE buffercan dramatically improve the performance of your batchjobs. An OUTMESSAGE buffer is automatically createdfor each cursor when the cursor is created. The defaultsize of the OUTMESSAGE buffer is 1K, which is bigenough for most single statement uses of theOUTMESSAGE buffer. (Note: If your SQL statement orbind data is bigger than your OUTMESSAGE buffer,SQLBase will simply carry the rest of the information inadditional LAN packets.) If you use BULK EXECUTE,you can increase the size of the OUTMESSAGE buffer toincrease the amount of information you can send in aLAN packet. You can use the SQLTalk command:

SET OUTMESSAGE 2000;

to set the OUTMESSAGE buffer for the session to 2,000bytes–or twice as big as the default buffer size.You can also use the following syntax in SQLWindows:

Call SqlSetOutMessage(hCursor, 2000)

where hCursor is the name of the cursor whoseOUTMESSAGE buffer you want to size and the secondparameter is the size, in bytes, you wish to set theOUTMESSAGE buffer to. The maximum size for anOUTMESSAGE buffer is 32K bytes.

Tip no. 3: Split up your jobSo you want faster? The overall throughput of a batch job

is determined by more than just the time that SQLBasetakes to process the database writes. The data has to besent from the client to the server, and the server has tosend an acknowledgment back to the client. Thiscommunication takes time, and the SQLBase server isn’tworking on the load process while it’s waiting oncommunications. If you still have to complete a batch jobin less time, you can split up the load into severaldifferent jobs. You can run each job from a separateworkstation, use more SQLBase cycles on processing thejobs, and increase the overall throughput of the system. Atthe bank mentioned earlier, the developers were able tostart eight jobs before experiencing any degradation in theperformance of any one job.

Tip no. 4: Load files locallyWell, if the communications between the client and theserver takes so much time, why not eliminate the need forit?

The SQLBase development team has done exactly thatin version 6.0 of SQLBase. With version 6.0, you can nowload files that are on the same server as the SQLBaseserver. SQLBase will understand that the load files arelocal and will load them directly. Eliminating the need tocommunicate over a LAN between the client applicationand the SQLBase server can dramatically improve theperformance of batch loads and unloads.

To load a file on the server from WinTalk or SQLTalk,use the following command:

LOAD file_type file_name ON SERVER;

where file_type is the type of load file (SQL, ASCII, and thelike) and file_name is the name of the file on the servermachine.

SQLTalk or WinTalk will load the file directly from theserver without having to expend resources for any datatransfer across the network.

Tip no. 5: Set recovery offStill not satisfied? There’s one more stupid batch trick leftfor you to try, but it really is stupid. Before I introduce it,let me just say you should never turn recovery off forSQLBase, because if SQLBase should crash in any waywith recovery turned off, you cannot recover from thecrash. (That’s why they call it RECOVERY OFF.) Now thatyou’ve heard that rather loud caveat, I’ll continue.

SQLBase, like any relational database, writes alldatabase changes to a log file. If the database or its serverever crashes, the database can be restored using the logfiles. If you’re doing a dedicated batch load of data, youonly care about the integrity of the database at two points:before you begin the load and after the load completes.

Continues on page 16

ProG u p t a

Experts Divulge Their Secrets!Doug Mitchell

This $49.95 book goes far beyond

the usual regurgitation of existing

documentation.

comprehensive guide to learning how to program usingSQLWindows. While it is a virtual smorgasbord ofadvanced SQLWindows topics written by many seasoneddevelopers, targeted for consumption by SQLWindowsdevelopers ranging from “accomplished” to “expert,” itisn’t what I consider a complete programming reference.However, all things considered, I still highly recommendthis book for every SQLWindows developer, with thepossible exception of a complete novice.

Not surprisingly, since several of the authors workdirectly for Gupta, Using demonstrates considerableinsight into SQLWindows. For example, if you’reinterested in learning about SQLWindows’ implementationof OLE2, QuickTabs (tab controls), the ComponentDeveloper Kit (CDK), or even the upcoming Dynalibs,this book will be of particular interest to you.

There’s a slight downside to the involvement ofGupta staff. The book is conspicuously lacking of criticalcomments about SQLWindows. It focuses onSQLWindows’ strengths and often ignores its weaknesses.

Section 1: Using DatabasesThis section deals with SQLWindows’ interaction withdatabases. Chapter 1 begins with the basics, covering theSQL access cycle (connecting, preparing, fetching, etc.),concurrency, locking, and database transactions. Whilethis chapter is meant to introduce key database concepts,it provides a surprising amount of useful detail.Subsequent chapters provide a more detailed inspection

For developers using ODBC, a wealth of informationis available in chapter 6, “ODBC Multi-User DatabaseConcepts.” Chapter 7, the last in this section, leverages thematerial covered in the previous chapters and discusseshow to build multi-database applications. I like thischapter because it discusses various tricks and traps indesigning an application that supports multiple back-ends. Overall, this section covers a lot of previouslyundocumented territory, making it a valuable resource for

At first glance, you mightthink Que’s Special Edition,Using Gupta SQLWindows 5,

self-proclaimed as “The MostComplete Reference,” is a

any serious SQLWindows developer.

Section 2: Elements ofObject-Oriented ProgrammingThis section starts with a concise and

effective introduction to key Object-OrientedProgramming (OOP) concepts such as objects, classes,encapsulation, inheritance, and polymorphism.

Chapter 9 builds on these OOP concepts and explainsSQLWindows’ class implementation and use ofinheritance. While the first half of the chapter dealingwith the different SQLWindows classes and the ClassEditor borders on typical documentation, the second halftakes up the slack by providing an excellent detaileddiscussion of inheritance. In particular, it covers how totake advantage of OOP within SQLWindows.

Chapter 10, the real gem of this section, providescomprehensive coverage of a critical, but often ill-documented, aspect of object-oriented programming:polymorphism. This chapter not only explainsSQLWindows’ two polymorphic mechanisms, messagesand late binding, but also explains the tradeoffs involvedin using each.

Section 3: Elements of SQLWindowsThis next section consists of a collection of SQLWindowsfeatures and functions. Topics include: the ever- populartable window, the (in)famous QuickObjects, the oftenunder-used Visual Toolchest, and ReportWindows. Inaddition, this section covers the Component DevelopmentKit (CDK), QuickTabs, and the upcoming Dynalibs.

Because chapter 11 discusses the table windowextensively—and because of the critical role tablewindows play in application development—the chaptershould be required reading for all SQLWindowsprogrammers. Two chapters are devoted to usingReportWindows. While I enjoyed the detail provided inchapter 12, “Reporting from SQLWindows,” it lacks adiscussion of the appropriateness of ReportWindows’ use.For example, while the client-based ReportWindows isexcellent for smaller reports, large batch printing isanother story, often requiring a server-based reportingtool. “Advanced Topics in ReportWindows,” chapter 13,



covers subjects such as customizing crosstabs, using anon-database source, OLE objects in reports, and (mypersonal favorite) how to “simulate” multiple detailblocks in your report. For developers looking to take fulladvantage of ReportWindows, these two chapters providevaluable detail and useful tips.

Chapter 14, “Introducing Dynalibs,” is quite a teaser;I had more questions after I read it than before. However,it’s hard to fault the author when you consider thechapter was written over a year before the release of thisupcoming feature. Chapter 15, “Introducing QuickTabs,”also provides fairly rudimentary documentation on thisnew 5.0.2 SQLWindows feature.Chapter 16, introducing the CDK, isinformative, because it provides notonly a brief survey of the CDKcapabilities, but also some useful andreusable code examples; however, theCDK warrants its own book to doproper justice. I found chapter 17,“Examination of QuickObjects,”fluffy, containing little more than what is found in theSQLWindows documentation.

Section 4: The Art and Scienceof Application DesignThis section discusses elements of application design. Thefirst chapter provides outstanding coverage ofSQLWindows’ implementation of Multiple DocumentInterface (MDI). Considering the level of detail provided,it’s obvious that the author had significant, first-handexperience. It’s essential to read if you’re consideringbuilding an MDI application. Tucked in the middle of thechapter is a related sidebar discussion of “named menus”that includes a useful code sample.

Chapters 21 and 22 discuss the design anddeployment of an application. Buried deep within chapter21 is an interesting segment on messaging, which includesa detailed discussion and an example of an inter-application message architecture. This architectureprovides rudimentary Dynamic Data Exchange (DDE)between multiple SQLWindows applications that’s easierto implement and has less overhead than a full-blownDDE implementation.

The final chapter in this section, chapter 23, coversone of the more complex topics in SQLWindows—DDE.While it’s impossible to cover DDE comprehensively in asingle chapter, the author provides a good introductionand reveals some neat DDE techniques. For example, thechapter describes a SQLWindows to Microsoft Word DDEconversation that sends commands to the Word server tosave, print, and close a document.

Section 5: Advanced TopicsThis collection of advanced object-oriented user interface

and programming techniques can help you turbo-chargeyour applications. I’ll mention a few of my favorites. AQuickObject (QO) interface simplifies reporting usingReportWindows. The ReportWindows QO interfacedemonstrates the use of undocumented SalOutline*functions and a ReportWindows API that is available onlyto third-party developers. While I would think twiceabout using undocumented functions in a productionapplication, the technique provides valuable insight intothe internals of SQLWindows.

Chapter 25, “Advanced User Interface Techniques,”provides many excellent tips on how to give your

applications a professional look andfeel. Many of these techniques takeadvantage of the Windows API.Examples include programmaticselection of text, the progress meter,startup “splash” windows, read-onlycontrols (but not disabled; text canstill be copied), and even three-statecheck boxes. Even if you’re

advanced, you’ll find at least one new trick here.Chapter 26, “Advanced Programming Techniques,” is

yet another collection of helpful programming tips. Itbegins with a useful discussion of DLLs; what they areand how to use them within the SQLWindowsenvironment. It also discusses how to determine yourapplication’s load path at runtime and how to keep trackof the Windows 3.1 system resources.

Section 6: Techniques from the ProsThe final section contains more advanced topics andtechniques. Considering that the authors of the previoussections are just as qualified as these “pros” (and somecases the same), the distinction implied by this section’stitle is unclear.

Chapter 27 focuses on the SQLWindows C compilerthat compiles internal functions into a DLL. If you plan toever make use of this facility, I highly recommend thischapter. It shows enormous insight into the feature bydemonstrating how to maximize the compiler’s potentialfor performance gains—not too surprising, given that it’swritten by the principal author of the SQLWindows Ccompiler himself!

Chapter 28 presents concepts and techniquescontributed by a variety of additional experts: the semi-sysmodal windows, programmatic selection of text (yetagain), splitting windows using a custom control class,deferring the repainting of windows, the debugger’slesser known features, and some other general tips andtricks. While some of these topics are a bit on the esotericside, this chapter is worth a look.

Chapter 29 introduces Object Linking and Embedding(OLE). The good news is that it covers OLE2. The badnews is that it’s too short! The detail it contains is not

Special Edition, Using GuptaSQLWindows 5David Holmes-Kinsella, et alQue Publishing, 0-78970-189-8


enough to do the topic justice. It does, however, introduceyou to yet another SQLWindows 5.0.2 feature.

The final chapter is a personal favorite of mine basedon its entertainment value rather than its utility. Chapter30, “Under the Wraps of SQLWindows,” is an explorationinto the undocumented features of SQLWindows. Not onlydoes the author reveal some of his favorite tricks, but healso explains how you can discover more.

Contents of the CDBecause the book contains many clever advanced featuresand programming techniques, the code in electronicformat is a real time-saver. Unfortunately, the quality ofthe CD’s contents is questionable; some chapters lack anysamples in electronic format. Other chapters makereference to files that are missing from the CD. In somecases, even when the file is present, it lacks comments oran application description, or contains randombreakpoints. These drawbacks indicate that the CD’sconstruction was rushed, reducing its value to the book.On the positive side, some of the code is provided inready-to-use .APL files. For example, users of theWindows API and SDK will enjoy an .APL with most ofthe popular API functions and constants predefined. TheCD also includes evaluation copies of third-partyproducts, such as class libraries, reporting tools, CASEtools, help and installation authoring tools, and more. Acopy of SQLWindows 5.0.1 Solo is even included.

ConclusionWhen multiple authors write an advanced topic booksuch as this one, they can combine their collectiveexperience. However, compared to Gugick’s single-handed effort, Holmes-Kinsella’s book suffers in terms ofoverall content consistency. The authors’ distinctivewriting styles are noticeable and affect the book’scontinuity. Also, since most of these chapters are stand-alone topics written by different authors, several conceptsare redundantly covered. For example, the programmaticselection of text technique is covered in both the“Advanced User Interface Techniques” and “AdvancedProgrammers Exchange” chapters. Finally, the groupingand division of the chapters into the various sections aresometimes perplexing. For example, “Advanced Topics onReportWindows” is in the “Elements of SQLWindows,”rather than in the “Advanced Topics” section.

Despite flow issues between chapters, a rushed jobwith the CD, and the book’s pro-Gupta bias, thiscompilation of advanced SQLWindows topics is aninvaluable reference because of its contents and should berequired reading for all professional SQLWindowsdevelopers. P

Doug Mitchell is a Principal with American Management Systems (AMS)

in Washington, D.C. and has been using SQLWindows for the last five

years. He has served as a SQLWindows instructor, presented at the last

three Gupta developer conferences, and currently presides over the D.C.-

area Gupta user group. Internet [email protected].

If you take the proper precautions, you can turnrecovery off while doing a batch load of data. Thedownside of this practice is that if a crash occurs, you willhave to restore the database and begin the job again. Theupside of the practice is that you can eliminate all I/O tothe log file, which will reduce the overall amount of I/Oby a significant amount. For a batch load, the tradeoff isoften worthwhile.

Now, do not just turn off recovery! (Did I mention that?)If you want to increase the performance of your batch jobby eliminating the overhead of recovery capability, youmust:

1. Back up your database.2. Stop all other database access.3. Turn off recovery logging with the SQLTalk/WinTalk

command.4. SET RECOVERY OFF.

5. Run the batch job.6. If the load is successful, turn recovery logging back

on with the SQLTalk/WinTalk command.7. SET RECOVERY ON.

If your batch job fails, you can restore your databaseand run the job again. (Future articles will discuss backupstrategies for SQLBase.)

And remember, don’t turn recovery off unless yourdatabase has been completely backed up, because if youcrash, your database is hosed.

ConclusionFor SQLBase, processing large batches of database writesis anomalous to its typical processing scenario. However,SQLBase can perform well in batch processing scenarios,especially when you can optimize its performance. Justtry a few stupid tricks to make it work. P

Rick Greenwald worked for Gupta in a variety of positions. Since leaving

Gupta he has been an independent analyst and writer and is currently

the staff technologist at Metamor Technologies in Chicago. Internet

[email protected].

Five Stupid Batch Tricks . . .Continued from page 13

Documents

GuptaPro - Jeff Luther/PC Design · •Centura Report Builder •Centura Ranger Centura Builder Centura Builder is the new, integrated development environment, akin to the SQLWindows