Getting Started with TRANSACT (32247-90007)

81
5 Automatic Error Handling and
Prototyping
This section will demonstrate how easy it is to develop a working prototype of an
application system by taking advantage of Transact’s power, in particular the automatic
error handling facility.
We will take a particular example and follow it from the initial prototype attempt until the
finished product emerges.
Usually, when prototyping of a system is discussed, it is thought of in terms of throwaway
code. This need not be the case with Transact. Unlike most other application development
tools, Transact is a complete procedural language. However, as an integral part of the
language, there are high level, more nonprocedural types of constructs that provide the
true power of the language.
These high-level constructs and facilities can be used to advantage to produce a working
prototype of a system. The prototype can then be reviewed with and even developed with
the user community until mutual agreement has been reached as to the functionality of
the system and its appearance to the user.
Because agreement can be reached much more quickly than with traditional languages,
prototyping is a viable tool to help get the users more involved. At the same time, the effort
of the application developer is not wasted because the code does not need to be thrown
away as the production system is developed. Instead, much of the code can be retained as
is, and only those procedures where Transact’s automatic facilities do not provide the
required control need to be expanded to provide the necessary control. The emphasis on
expansion is there because typically the code is not rewritten at this point, but additional
options are added to existing Transact constructs and additional code is written to provide
the necessary control.
The example that we will develop in this chapter consists of providing the functionality to
add an order to the database. We could prototype the database design, forms design, etc.,
as well as the program design, but let's assume that there are valid reasons to have the
database design remain as it is. We will concentrate on how we present data to the user
and get data from the user.
This program is our first attempted solution: