Application development environments (ADEs) play a critical, visible role in a test software framework.

With these tools, the system developer designs and integrates the system that takes measurements, displays information to the end user, connects with other applications, and much more. Due to the ever increasing role of software in test system implementation, system developers will spend most of their development time working with an ADE. It is critical to select an ADE that not only is easy to use, but also can support multiple platforms and integrate easily with measurement and control services such as drivers. Other features that should be considered when selecting an ADE for the development of your test system are its presentation and reporting features, how protected you are from the obsolescence of the product, and what kind of training and support is available worldwide.
Factors to consider when selecting an ADE Ease of use Measurements and Analysis capabilities Integration with Measurement and Control Drivers Training and support Platform Independence Presentation and Reporting Features Protection against Obsolescence DB2 Call Level Interface (CLI) versus embedded dynamic SQL An application that uses an embedded SQL interface requires a precompiler to convert the SQL statements into code, which is then compiled, bound to the database, and executed. In contrast, a DB2 CLI application does not have to be precompiled or bound, but instead uses a standard set of functions to execute SQL statements and related services at run time. This difference is important because, traditionally, precompilers have been specific to each database product, which effectively ties your applications to that product. DB2 CLI enables you to write portable applications that are independent of any particular database product. This independence means DB2 CLI applications do not have to be recompiled or rebound to access different DB2(R) databases, including host system databases. They just connect to the appropriate database at run time. The following are differences and similarities between DB2 CLI and embedded SQL:

DB2 CLI does not require the explicit declaration of cursors. DB2 CLI has a supply of cursors that get used as needed. The application can then use the generated cursor in the normal cursor fetch model for multiple row SELECT statements and positioned UPDATE and DELETE statements. The OPEN statement is not used in DB2 CLI. Instead, the execution of a SELECT automatically causes a cursor to be opened. Unlike embedded SQL, DB2 CLI allows the use of parameter markers on the equivalent of the EXECUTE IMMEDIATE statement (the SQLExecDirect() function). A COMMIT or ROLLBACK in DB2 CLI is typically issued via the SQLEndTran() function call rather than by executing it as an SQL statement, however, doing do is permitted. DB2 CLI manages statement related information on behalf of the application, and provides an abstract object to represent the information called a statement handle. This handle eliminates the need for the application to use product specific data structures.

Similar to the statement handle, the environment handle and connection handle provide a means to refer to global variables and connection specific information. The descriptor handle describes either the parameters of an SQL statement or the columns of a result set. DB2 CLI applications can dynamically describe parameters in an SQL statement the same way that CLI and embedded SQL applications describe result sets. This enables CLI applications to dynamically process SQL statements that contain parameter markers without knowing the data type of those parameter markers in advance. When the SQL statement is prepared, describe information is returned detailing the data types of the parameters. DB2 CLI uses the SQLSTATE values defined by the X/Open SQL CAE specification. Although the format and most of the values are consistent with values used by the IBM(R) relational database products, there are differences. (There are also differences between ODBC SQLSTATES and the X/Open defined SQLSTATES).

Despite these differences, there is an important common concept between embedded SQL and DB2 CLI: DB2 CLI can execute any SQL statement that can be prepared dynamically in embedded SQL. Note: DB2 CLI can also accept some SQL statements that cannot be prepared dynamically, such as compound SQL statements. Each DBMS may have additional statements that you can dynamically prepare. In this case, DB2 CLI passes the statements directly to the DBMS. There is one exception: the COMMIT and ROLLBACK statements can be dynamically prepared by some DBMSs but will be intercepted by DB2 CLI and treated as an appropriate SQLEndTran() request. However, it is recommended you use the SQLEndTran() function to specify either the COMMIT or ROLLBACK statement.

Dynamic SQL Versus Static SQL The question of whether to use static or dynamic SQL for performance is usually of great interest to programmers. The answer depends on your situation. Use the following table when deciding whether to use static or dynamic SQL. Considerations such as security dictate static SQL, while environmental considerations (for example, using DB2 CLI or the CLP) dictate dynamic SQL. When making your decision, consider the following recommendations on whether to choose static or dynamic SQL in a particular situation. In the following table, 'Either' means that there is no advantage to either static or dynamic SQL. Note: These are general recommendations only. Your specific application, its intended usage, and working environment dictate the actual choice. When in doubt, prototyping your statements as static SQL, then as dynamic SQL, then comparing the differences is the best approach. Table 1. Comparing Static and Dynamic SQL
Consideration Likely Best Choice

Time to run the SQL statement:

Less than 2 seconds 2 to 10 seconds More than 10 seconds

Static Either Dynamic

Data Uniformity

Table 1. Comparing Static and Dynamic SQL

Uniform data distribution Slight non-uniformity Highly non-uniform distribution

Static Either Dynamic

Range (<,>,BETWEEN,LIKE) Predicates Very Infrequent Occasional Frequent Static Either Dynamic

Repetitious Execution Runs many times (10 or more times) Runs a few times (less than 10 times) Runs once Either Either Static

Nature of Query Random Permanent Dynamic Either

Run Time Environment (DML/DDL) Transaction Processing (DML Only) Mixed (DML and DDL - DDL affects packages) Mixed (DML and DDL - DDL does not affect packages) Either Dynamic Either

Frequency of RUNSTATS Very infrequently Regularly Frequently Static Either Dynamic

In general, an application using dynamic SQL has a higher start-up (or initial) cost per SQL statement due to the need to compile the SQL statements before using them. Once compiled, the execution time for dynamic SQL compared to static SQL should be equivalent and, in some cases, faster due to better access plans being chosen by the optimizer. Each time a dynamic statement is executed, the initial compilation cost becomes less of a factor. If multiple users are running the same dynamic application with the same statements, only the first application to issue the statement realizes the cost of statement compilation. In a mixed DML and DDL environment, the compilation cost for a dynamic SQL statement may vary as the statement may be implicitly recompiled by the system while the application is running. In a mixed environment, the choice between static and dynamic SQL must also factor in the frequency in which packages are invalidated. If the DDL does invalidate packages, dynamic SQL may be more efficient as only those queries executed are recompiled when they are next used. Others are not recompiled. For static SQL, the entire package is rebound once it has been invalidated. Now suppose your particular application contains a mixture of the above characteristics, and some of these characteristics suggest that you use static while others suggest dynamic. In this case, there is no obvious decision, and you should probably use the method you have the most experience with, and with which you feel most comfortable. Note that the considerations in the above table are listed roughly in order of importance. Note: Static and dynamic SQL each come in two types that make a difference to the DB2 optimizer. These types are: 1. Static SQL containing no host variables

This is an unlikely situation which you may see only for:

o o

Initialization code Novice training examples

This is actually the best combination from a performance perspective in that there is no runtime performance overhead, and the DB2 optimizer's capabilities can be fully realized. 2. Static SQL containing host variables

This is the traditional legacy style of DB2(R) applications. It avoids the run time overhead of a PREPARE and catalog locks acquired during statement compilation. Unfortunately, the full power of the optimizer cannot be utilized because the optimizer does not know the entire SQL statement. A particular problem exists with highly non-uniform data distributions. 3. Dynamic SQL containing no parameter markers

This is the typical style for random query interfaces (such as the CLP), and is the optimizer's preferred flavor of SQL. For complex queries, the overhead of the PREPARE statement is usually offset by the improved execution time. 4. Dynamic SQL containing parameter markers

This is the most common type of SQL for CLI applications. The key benefit is that the presence of parameter markers allows the cost of the PREPARE to be amortized over the repeated executions of the statement, typically a select or insert. This amortization is true for all repetitive dynamic SQL applications. Unfortunately, just like static SQL with host variables, parts of the DB2 optimizer will not work because complete information is unavailable. The recommendation is to use static SQL with host variables or dynamic SQL without parameter markers as the most efficient options.

When to use DB2 CLI or embedded SQL Which interface you choose depends on your application. DB2 CLI is ideally suited for query-based graphical user interface (GUI) applications that require portability. The advantages listed above, may make using DB2 CLI seem like the obvious choice for any application. There is however, one factor that must be considered, the comparison between static and dynamic SQL. It is much easier to use static SQL in embedded applications. Static SQL has several advantages:

Performance

Dynamic SQL is prepared at run time, static SQL is prepared at precompile time. As well as requiring more processing, the preparation step may incur additional network-traffic at run time. The additional network traffic can be avoided if the DB2 CLI application makes use of deferred prepare (which is the default behavior). It is important to note that static SQL will not always have better performance than dynamic SQL. Dynamic SQL is prepared at runtime and uses the database statistics available at that

time, whereas static SQL makes use of database statistics available at BIND time. Dynamic SQL can make use of changes to the database, such as new indexes, to choose the optimal access plan, resulting in potentially better performance than the same SQL executed as static SQL. In addition, precompilation of dynamic SQL statements can be avoided if they are cached.

Encapsulation and Security

In static SQL, the authorizations to access objects (such as a table, view) are associated with a package and are validated at package binding time. This means that database administrators need only to grant execute on a particular package to a set of users (thus encapsulating their privileges in the package) without having to grant them explicit access to each database object. In dynamic SQL, the authorizations are validated at run time on a per statement basis; therefore, users must be granted explicit access to each database object. This permits these users access to parts of the object that they do not have a need to access.

Embedded SQL is supported in languages other than C or C++. For fixed query selects, embedded SQL is simpler.

If an application requires the advantages of both interfaces, it is possible to make use of static SQL within a DB2 CLI application by creating a stored procedure that contains the static SQL. The stored procedure is called from within a DB2 CLI application and is executed on the server. Once the stored procedure is created, any DB2 CLI or ODBC application can call it. It is also possible to write a mixed application that uses both DB2 CLI and embedded SQL, taking advantage of their respective benefits. In this case, DB2 CLI is used to provide the base application, with key modules written using static SQL for performance or security reasons. This complicates the application design, and should only be used if stored procedures do not meet the applications requirements. Ultimately, the decision on when to use each interface, will be based on individual preferences and previous experience rather than on any one factor.

DIFFERENCE BETWEEN DYNAMIC(interactive) and STATIC(embedded) SQL :

The difference is the time at which the BIND occurs. In static mode, the bind is done prior to the execution and is stored in a PLAN. In dynamic mode, the BIND occurs at execution time. STATIC sql(embedded) : It is hardcoded in the program itself and the changeable value is the value in the host variables. DYNAMIC sql : It has the capability of changing the columns,tables during the execution of prg. It doesnt contain any host variables.

SQL Type

Preparation

Speed

Flexibility

Security

Dynamic Run-time, during execution

Slower than embedded or static

Most flexible

Least secure

Embedde Design-time, during Faster than d program preparation dynamic or static Static Design-time, during Faster than package preparation dynamic

Least flexible

Most secure

Less flexible than dynamic, but more flexible than embedded

More secure than dynamic

Static and dynamic SQL statement execution in embedded SQL applications Both static and dynamic SQL statement execution is supported in embedded SQL applications. The decision to execute SQL statements statically or dynamically requires an understanding of packages, how SQL statements are executed at run-time, host variables, parameter markers, and how these things are related to application performance. Static SQL in embedded SQL programs An example of a statically executed statement in C is:
/* select values from table into host variables using STATIC SQL and print them*/ EXEC SQL SELECT id, name, dept, salary INTO :id, :name, :dept, :salary FROM staff WHERE id = 310; printf(" %3d %-8.8s %4d %7.2f\n\n", id, name, dept, salary);

Dynamic SQL in embedded SQL programs An example of a dynamically executed statement in C is:
/* Update column in table using DYNAMIC SQL*/ strcpy(hostVarStmtDyn, "UPDATE staff SET salary = salary + 1000 ?"); EXEC SQL PREPARE StmtDyn FROM :hostVarStmtDyn; EXEC SQL EXECUTE StmtDyn USING :dept;

WHERE dept =