Beruflich Dokumente
Kultur Dokumente
Author:
Oriana Merlo
Table of Contents
Table of Contents.................................................................................................................................... ii
Executive Summary................................................................................................................................ 1
Introduction............................................................................................................................................ 2
High Performance vs. Database Independence............................................................................... 2
DataServer Configurations..................................................................................................................... 3
Local DataServer and Local Oracle Database ....................................................................................... 3
Local DataServer and Remote Oracle Database .................................................................................... 3
Remote DataServer and Local Oracle Database .................................................................................... 4
Remote DataServer and Remote Oracle Database ................................................................................. 4
SQL*Net or Net8 vs. Progress Networking .......................................................................................... 4
Database Design ..................................................................................................................................... 5
Naming Conventions ........................................................................................................................... 5
Database Limitations ........................................................................................................................... 5
Data Types .......................................................................................................................................... 5
Additional Database Objects Required ................................................................................................. 5
Arrays.................................................................................................................................................. 6
Case-Insensitive Indexes ...................................................................................................................... 6
RECIDs............................................................................................................................................... 6
Word Indexes ...................................................................................................................................... 7
Unknown Values / NULLs / Zero-Length Character Strings ................................................................. 7
Fixed vs. Variable Length Character Strings in Oracle.......................................................................... 7
Trailing Blanks .................................................................................................................................... 7
Progress To Oracle Database Conversion Utility .................................................................................. 8
Application Design ................................................................................................................................. 9
Unsupported Syntax............................................................................................................................. 9
Utilizing Oracle-Specific Functionality ................................................................................................ 9
Stored Procedures ........................................................................................................................... 9
Native Oracle SQL Syntax Support .................................................................................................. 9
Optimizer Hints ............................................................................................................................... 9
Transactions ........................................................................................................................................ 9
Stored Procedures and Transaction Scoping...................................................................................10
Constraint Violations / Trigger Execution.......................................................................................10
Triggers..............................................................................................................................................10
Record Locking ..................................................................................................................................10
No SHARE-LOCK Support in Oracle..............................................................................................11
Automatic Optimistic Locking Support............................................................................................11
Cursor Repositioning ..........................................................................................................................11
RECIDs and ROWIDs ........................................................................................................................12
Record Scoping / Availability .............................................................................................................13
Ordering of Records............................................................................................................................14
Query Tuning..........................................................................................................................................14
Field Lists ......................................................................................................................................14
Lookahead Cursors ........................................................................................................................14
Progress 4GL vs. SQL ....................................................................................................................15
Join-By-SQLDB .............................................................................................................................16
December, 1998
Page ii
December, 1998
Page iii
Executive Summary
The past decade has seen many companies invest a significant amount of both time and resources into
establishing corporate database standards. With hardware, operating systems and networking products
giving way to open technologies, those same companies are frustrated in their efforts to grow by being
inextricably bound to application suppliers who provide solutions that run only on their chosen database.
A single database system today is capable of acting as the source for a variety of applications, from
traditional on-line transaction processing (OLTP) and decision support systems (DSS), to todays currently
hot technologies like data mining and internet transaction processing (ITP). Customers want high
performing solutions, and they want them to fit in with their existing operating environments, without
having to duplicate data to a wide variety of different database management systems.
Progress Software Corporation's (PSC) DataServer technology allows applications created with the
Progress 4GL or Progress WebSpeed development environments to connect to a variety of nonProgress data sources. The DataServer accepts the request for data from the application, translates it into a
format and syntax suitable for the underlying database, and passes the request on. The data source then
accepts the request, processes it as if it were a native client, and sends the information back to the
DataServer. The DataServer will then adjust the result set into the format expected by the application
before passing it on.
This paper will help you create high performance applications with the Progress 4GL and WebSpeed
toolsets to integrate with an Oracle relational database management system (RDBMS). The focus of this
paper is on Progress tools and technology. It explains how the Progress Oracle DataServer supports the
development and delivery of high performance applications on an Oracle database.
Progress provides you with the tools to build mission-critical applications for a wide variety of deployment
configurations, without changing the application logic. This allows developers to focus on solving business
problems, not reacting to changes in the computing infrastructure.
December, 1998
Page 1
Introduction
Creating an application to run efficiently over an Oracle relational database management system (RDBMS)
requires the integration of a number of technologies: the development toolset used to create the application,
the underlying Oracle database technology, a knowledge of operating systems and networked
environments, and the connectivity software used for access to the Oracle database.
The Progress 4GL and WebSpeed development tools are tightly integrated with the Progress RDBMS,
however, the Progress Oracle DataServer allows you to use these toolsets to develop applications that can
be deployed with an Oracle RDBMS. The Progress Oracle DataServer provides optimized database
connectivity to the Oracle database. This connectivity technology, however, does require thorough
understanding. While the Progress 4GL and WebSpeed toolsets make it easy to develop on-line transaction
processing (OLTP) and internet transaction processing (ITP) applications, subtle differences in the Oracle
and Progress databases make it necessary for developers to be mindful of their data source during the
application development phase. New development work can be undertaken so that resulting applications
can run equally well over either data manager. Application developers who have existing Progress 4GL or
WebSpeed applications may find that some parts of their application logic may need to be rewritten to cater
to these database differences.
December, 1998
Page 2
DataServer Configurations
There are four possible configurations when using the Progress Oracle DataServer. Details of each
configuration are given below.
Schema
Holder
Oracle
Progress
Client
Progress Oracle
DataServer
Machine 1
Progress
Client
Schema
Holder
Progress Oracle
DataServer
Oracle
Networking
SQL*Net
or Net8
SQL*Net
or Net8
Oracle
Machine 2
Machine 1
December, 1998
Page 3
Progress
Client
Progress Oracle
DataServer
Schema
Holder
Machine 1
Progress
Networking
Schema
Holder
Oracle
Machine 2
Progress
Client
Schema
Holder
Machine 1
Schema
Holder
Progress
Networking
Progress Oracle
DataServer
SQL*Net
or Net8
Oracle
Networking
Machine 2
Oracle
SQL*Net
or Net8
Machine 3
December, 1998
Page 4
Database Design
Because of the inherent differences between the Progress and Oracle relational database managers, care
needs to be taken when designing a database architecture for Oracle to be accessed by a Progress-based
application. The following sections discuss the differences between the Progress and Oracle data managers,
and how the DataServer resolves them.
Naming Conventions
The Oracle database management system has certain naming conventions that must be adhered to for
naming database objects such as tables, columns, sequences, indexes, etc. These conventions forbid the use
of some special characters that are otherwise acceptable in a Progress RDBMS. The Oracle product
documentation will offer more details on characters to be avoided. As a general rule, avoid the use of
hyphens (-) and percent signs (%) in all object names.
Be mindful of any limits on the length of object names within the Oracle database (Progress has a
maximum of 32 per table name, Oracle only 30) remembering that the Progress Oracle DataServer may
need to append extra characters to an object name to support extended Progress 4GL compatibility. In
general, try and limit your object names to 25 characters.
The Oracle database management system has its own set of reserved words that cannot be used to name
database objects. Avoid the use of these reserved words (as well as all Progress reserved words) when
naming objects in an Oracle database.
Please refer to the Progress Oracle DataServer Guide for further information.
Database Limitations
Depending on the version of the Oracle RDBMS, there may be certain physical limits imposed by the
database that can cause problems when converting a Progress database to this database management
system. One example of a particularly problematic limitation is Oracle7 s limit of 254 columns in a
single table. (This limitation has been increased to 1,000 columns in Oracle8.) There are several instances
where an equivalent Oracle table will require more columns than its Progress equivalent, such as to
accommodate Progress arrays, case-insensitive indexes, and RECID values. These scenarios are outlined in
more detail below. Appendix A contains a sample Progress 4GL program to calculate the number of
columns a Progress table would need in an equivalent Oracle table.
For further information on other limits, please refer to the Progress Oracle DataServer Guide, and your
Oracle documentation.
Data Types
The Oracle data manager has specific data types that vary from those of the Progress database. The
Progress Oracle DataServer translates these data types as closely as possible into Progress equivalents.
When a particular data type has more than one valid Progress equivalent, the DataServer supplies a default
data type. The Progress schema holder contains these Progress data type mappings for each underlying
column. You can manually change the default data type mapping in the schema holder using the Progress
Data Dictionary. One particular example is the single digit data type NUMBER(1) in Oracle. This can map
to a single digit INTEGER data type (9(1)), or a LOGICAL data type in Progress.
For further details on Oracle data types and their equivalent Progress mappings, please refer to the Progress
Oracle DataServer Guide.
Page 5
If Progress arrays are used within an application, a separate column will need to be created in an
Oracle table for every element of the array.
If case-insensitive indexes are used within a Progress database, a secondary column and additional
index need to be created in the Oracle database to support case-insensitive indexed retrieval.
If Progress RECIDs are used within an application, additional columns and sequences must be created
in Oracle to support their use.
These additional database objects can be created automatically when using the Progress-to-Oracle
conversion utility, protoora. This utility is described in more detail later in this document.
Each of these scenarios is described in more detail later on in this document. These extra columns and
indexes are masked from the developer or end user by use of the Progress schema holder.
Please refer to the Progress Oracle DataServer Guide for further information.
Please note that the creation of multiple fields for array representation, the addition of columns to support
case insensitive indexing, and RECID columns for scrolling demand close investigation because of limits to
the number of columns per table and the number of components per index imposed by the Oracle7
RDBMS. Appendix A contains a sample Progress 4GL program to calculate the number of columns a
Progress table would need in an equivalent Oracle table.
Arrays
The Oracle data manager does not support arrays in the way the Progress RDBMS does. However, the
Progress Oracle DataServer allows you to extend this array support into an Oracle database. As an example,
a Progress array of 12 elements would be implemented in Oracle by creating 12 distinct fields in a certain
order, and with a specific naming convention (outlined in the Progress Oracle DataServer Guide). The
Progress Oracle DataServer will then recognize these fields as forming an array, which the 4GL can access
in its normal fashion.
Please note that the creation of multiple fields for array representation demands close investigation because
of limits to the number of columns per table imposed by the Oracle7 RDBMS. Appendix A contains a
sample Progress 4GL program to calculate the number of columns a Progress table would need in an
equivalent Oracle table.
Case-Insensitive Indexes
By default, all character indexes defined in a Progress database will be case-insensitive (for example, the
letter a is equivalent to A in a sorting algorithm). The Oracle RDBMS does not provide caseinsensitive indexing. Therefore, as an example, the letter a will sort differently than its uppercase
equivalent A. The Progress Oracle DataServer can mask this difference by supporting the use of a
specially named column in the Oracle table (storing only uppercase values of the original column), and an
index on that column. If this table is to be updated by non-Progress applications, then an Oracle database
trigger should also be created to populate this shadow column with an uppercase value of the original
column.
Please refer to the Progress Oracle DataServer Guide for more information on the naming conventions of
these columns and methods for populating them.
Please note that the addition of columns to support case-insensitive indexing demands close investigation
because of limits to the number of columns per table imposed by the Oracle7 RDBMS. Appendix A
contains a sample Progress 4GL program to calculate the number of columns a Progress table would need
in an equivalent Oracle table.
RECIDs
The Progress Oracle DataServer will support RECID functionality in an Oracle database through the use of
an additional unique integer column on the table (called PROGRESS_RECID). This additional column will
December, 1998
Page 6
also require an index, and a specially named sequence to populate it. The Progress Oracle DataServer will
automatically increment the sequence, populate the PROGRESS_RECID field, and modify the index when
new records are added to the table through the Progress 4GL interface. If records are to be added to the
table from outside of a Progress environment, the PROGRESS_RECID field will need to be updated
manually. An Oracle database trigger is best suited to automating this process. Refer to the Application
Design section of this whitepaper for a further discussion of using ROWIDs and RECIDs.
Please note that the creation of PROGRESS_RECID columns demands close investigation because of
limits to the number of columns per table imposed by the Oracle7 RDBMS. Appendix A contains a sample
Progress 4GL program to calculate the number of columns a Progress table would need in an equivalent
Oracle table.
Word Indexes
Due to technical differences between the Oracle and Progress RDBMSs, word indexes are not supported
with the Progress Oracle DataServer. One possible workaround for this problem involves keeping the
column to be word indexed in a separate Progress database with links to the originating record in the Oracle
data manager.
Trailing Blanks
Oracle handles trailing blanks differently than Progress, even when the field is defined as a VARCHAR2
character string. This presents problems, particularly when using a SUBSTRING function to obtain a string
to store in the database. This string will be padded with blanks by Oracle if it is not as long as the
SUBSTRING definition. This is not a problem when running an application against a Progress database. As
an example, if we use the SUBSTRING(4,4) function on the character string YELLOW, Progress will
return the three character string LOW. Oracle however, will return the four character string LOW
(note one trailing blank space).
As a general rule, it is good practice to trim trailing blanks from character strings before assigning them to
the database.
December, 1998
Page 7
December, 1998
Page 8
Application Design
The Progress 4GL may behave differently when accessing an Oracle database than it would when accessing
a Progress-based one. The following sections discuss these behavioral differences, how the DataServer
resolves them, and techniques that should be implemented in application design to allow for both high
performance and database independence.
Unsupported Syntax
Due to inherent differences between the Oracle and Progress RDBMSs, there are some Progress 4GL
statements and functions that do not behave as expected, or will not work with the Progress Oracle
DataServer. Please refer to the Progress Oracle DataServer Guide for the latest information on
unsupported Progress 4GL functionality.
Stored Procedures
The Progress Oracle DataServer supports the use of Oracle PL/SQL stored procedures, stored
functions, and packages. These Oracle objects can be called directly from the Progress 4GL via
the RUN STORED-PROC command. By running stored procedures, processing is moved off
the Progress client, onto the database server machine. Stored procedures are useful in reducing
network traffic when aggregations of large numbers of records need to be performed, or when
performing mass modifications to database records.
Optimizer Hints
The Oracle database allows the passing of hints to the Oracle optimizer to determine (among
other things) which index to use in resolving a query. The Progress Oracle DataServer supports
the use of these index hints. In cases where performance might be improved by hinting an
index to Oracle, these hints should be used within the Progress 4GL syntax.
Please refer to the Progress Oracle DataServer Guide for more details on how to use Oracle
hints.
Transactions
The Oracle data manager handles transaction rollback and recovery through its own internal mechanisms,
however, Progress 4GL transaction scoping rules still apply.
December, 1998
Page 9
In Progress, transactions end at the end of the outermost block where an update takes place. When a
transaction that updates an Oracle database ends successfully, the Progress Oracle DataServer sends a
COMMIT message to the Oracle data manger. If the transaction is interrupted, Progress sends a
ROLLBACK message to the Oracle RDBMS.
If you modify data in more than one database in a single transaction (for example, a Progress database and
an Oracle database), Progress uses a two-phase commit protocol to minimize the chance of database
corruption wherever possible. When using distributed Oracle databases, the changes to the Oracle database
are performed first using Oracles own two-phase commit protocol, then the changes to the Progress
database are committed.
Please refer to the Progress Oracle DataServer Guide for more details on using the two-phase commit
protocol.
Triggers
If applications outside of the Progress environment are accessing the same Oracle tables as a Progressbased application through the Progress Oracle DataServer, then these native applications will only be
affected by Oracles database triggers. If implemented, Progress client triggers will fire in addition to these
Oracle database triggers only for Progress-based applications. If there are both Progress client triggers and
Oracle database triggers, the Progress client triggers will fire before the Oracle database triggers.
You can restrict Progress client triggers from executing when using Oracle databases with the DBTYPE
function. For example, the following code would only fire a trigger when running on a Progress database:
IF DBTYPE(dbname) = "PROGRESS" THEN DO:
{triggers.i}
END.
Record Locking
Both the Progress and Oracle databases implement record level locks. However, there are differences in the
types of locks that can be taken out on a record. These differences are described in more detail below. In
general, it is best to use optimistic record locking to mask these differences. Optimistic locking involves
reading records with NO-LOCK, and re-reading them again at update time with an exclusive lock. This will
mean the records are locked for the shortest time possible.
December, 1998
Page 10
Please refer to the Progress Oracle DataServer Guide for more details on locking techniques.
Cursor Repositioning
Progress uses cursors to keep track of where it is within a table. A cursor is like a pointer to consecutive
records in a table. For example, Progress uses cursors when it processes statements that return a set of
records (such as the FOR EACH or OPEN QUERY statements). Progress maintains cursor positioning
across queries. The Progress Oracle DataServer supports this behavior for tables in Oracle that have a
unique index on a mandatory integer column or tables that contain the PROGRESS_RECID column.
December, 1998
Page 11
When a FIND FIRST/LAST statement is issued, Oracle builds a result set that might include every record
in a table. Performance will improve if the statement is qualified with a WHERE clause to reduce the size
of the result set (however this still will not perform as well as a FOR EACH or OPEN QUERY statement).
Cursor repositioning behaves with the Progress Oracle DataServer as it does with Progress databases,
except when an Oracle database fails to find a record. In this case, the cursor in a Progress database is
located after the last record that was read. In the Oracle database, a failed search does not affect the cursor
if a single index is used.
For example, assume a result is made up of customer records 1, 2, 3, 4 and 5, and the cursor is positioned at
the last record (i.e. customer number 5).
5
cursor
If a FIND NEXT customer statement is issued (which uses a single index), the cursor moves as follows:
Progress Database:
Oracle Database:
1
cursor
5
cursor
(unchanged)
Regardless of which data source is used, the Progress 4GL functionality behaves consistently when this
occurs. The following statement, for example:
IF AVAILABLE customer
THEN DISPLAY customer.
ELSE MESSAGE "No customer record found".
will display the message No customer record found in each of the above situations, regardless of where
the cursor is positioned.
PROGRESS_RECID column
If a PROGRESS_RECID column is selected, then both the RECID and
ROWID Progress 4GL functions can be used in a Progress 4GL program.
December, 1998
Page 12
2.
Unique index on a single, mandatory, NUMBER column with precision <10 or undefined and
scale 0 or undefined
If a unique indexed column is selected, then both the RECID and ROWID
Progress 4GL functions can be used in a Progress 4GL program.
3.
The native Oracle ROWID typically provides the fastest access to a record. However, the native ROWID
does not support the Progress FIND PREV/LAST statement or cursor repositioning.
When the previous example is run against a Progress database, customer number 111 will be displayed.
The Progress Oracle DataServer, however, will return an error, as the new record does not get written back
to the Oracle database until the end of the record scope (in this case after the DISPLAY xcust statement).
This problem can be corrected in the following manner:
DEFINE BUFFER xcust FOR customer.
CREATE customer.
cust-num = 111.
VALIDATE customer. /* or RELEASE customer. */
FIND xcust WHERE xcust.cust-num = 111.
DISPLAY xcust.
If you are using the NO-ERROR option and the SESSION-STATUS:ERROR function to do your own
error handling, you should use the VALIDATE statement after you have created or updated the record.
This will enable you to trap and handle errors returned from the underlying data manager. To execute on a
Progress database, the previous code might be written as follows:
DEFINE BUFFER xcust FOR customer.
CREATE customer.
ASSIGN cust-num = 111 NO-ERROR.
IF ERROR-STATUS:ERROR
THEN DO:
MESSAGE "Error Creating Record".
END.
ELSE DO:
FIND xcust WHERE xcust.cust-num = 111.
DISPLAY xcust.
END.
December, 1998
Page 13
If a record with a cust-num of 111 already exists in the database, the Progress database will return the
Error Creating Record message, otherwise the record is created as per requested, and displayed from the
xcust buffer. However, when using the Progress Oracle DataServer, the customer record will not be visible
in the xcust buffer, as the record will not be written back to the Oracle database until the end of this
procedure. In order to emulate the behavior expected of a Progress database, the procedure can be modified
as follows to run against Oracle:
DEFINE BUFFER xcust FOR customer.
CREATE customer.
ASSIGN customer.cust-num = 111 NO-ERROR.
VALIDATE customer NO-ERROR.
IF ERROR-STATUS:ERROR
THEN DO:
MESSAGE "Error Creating Record".
END.
ELSE DO:
FIND xcust WHERE xcust.cust-num = 111.
DISPLAY xcust.
END.
The VALIDATE statement forces the record to be written to the Oracle database immediately. The NOERROR option ensures that user-defined error processing is invoked. The RELEASE customer NOERROR statement can also be used here, but it has the side effect of deleting the record from the client
buffers. The application would have to refetch the record from the database if it needs to access it again.
Ordering of Records
The Progress 4GLs advanced data retrieval statements, FIND <next> <prev> <first> <last> table-name
and FOR EACH table-name, coupled with the Progress RDBMS, guarantee that records are returned in a
specific order to the client. There may be instances where the Oracle database manager returns an
inconsistent sort order. If your application depends on sorted data, you should always explicitly specify
desired sort order and index criteria in your Progress 4GL statement. This can create performance
overhead, so it should only be used when the sort order is critical.
Query Tuning
The Progress Oracle DataServer provides several features to application developers to fine-tune queries to
be sent to Oracle. Further details on all the following options can be found in the Progress Oracle
DataServer Guide.
Field Lists
A feature introduced in the Version 8 Progress Oracle DataServer is the option of specifying
field lists for a query. This allows the Oracle database manager to only send back to the client
those fields of the record that were requested in the query (rather than every column in the
record). This can dramatically decrease the amount of network traffic in a client/server
environment, when records are read. It can also improve performance (to a lesser extent) in
host-based processing environments.
Field lists will only work with FOR EACH or OPEN QUERY statements. In order to take
advantage of these performance improvements, it is recommended that all FIND statements be
converted to equivalent FOR EACH or OPEN QUERY statements wherever possible.
Lookahead Cursors
The Progress Oracle DataServer caches results sets from the Oracle database to enhance
performance. It caches as much data as fits in its allocated cache size. Depending on what kind
of cursor a query is using the DataServer caches row identifiers or entire records:
December, 1998
Page 14
Standard cursors The DataServer caches row identifiers for the results set. When a
record needs to be read from the results set, its row identifier is retrieved from the cache
and a new database query is generated to access the entire record.
Lookahead cursors The DataServer caches complete records (or partial records as
specified by a field list). Lookahead cursors fetch as many records as can fit in the
allocated cache, limiting the number of database accesses, and thereby improving
performance. When a record is required, its values are simply retrieved from the cache.
This can lead to data consistency problems if a records value in the database was changed
by another user after a lookahead cursor was used to read its value.
Using lookahead cursors results in behavior that is different from Progress because they do not
see any changes made to the records in the cache. Specify QUERY-TUNING NOLOOKAHEAD for behavior that is consistent with Progress (but be aware that performance
may suffer as a consequence).
December, 1998
Page 15
Join-By-SQLDB
Another query tuning option introduced in Progress Version 8 is the ability to direct the Oracle
database manager to perform a querys join on the server. This is preferable to the default
action of sending two result sets down to the client (very costly in a networked environment)
and having that client (often a less powerful machine than the server) perform the join.
This JOIN-BY-SQLDB option (in either a FOR EACH or OPEN QUERY statement) should
perform better than a send-sql-statement stored procedure join for three major reasons:
1. JOIN-BY-SQLDB will do an array fetch.
2. JOIN-BY-SQLDB will ship multiple result rows in a single network message.
3. JOIN-BY-SQLDB will eliminate redundant information.
For example, consider a customer table with exactly 2 customers, each with 10,000 orders, and
the following 4GL code:
FOR EACH customer, EACH order OF customer:
. . . .
END.
If the server performs the join, the client will receive the first customer, all of their 10,000
order rows, and then the second customer and their 10,000 order rows. If this join is performed
with a send-sql-statement stored procedure (or Progress/SQL SELECT pass-through), 20,000
result rows will be shipped to the client. Each of the first 10,000 result rows will contain all of
the columns from the customer table with the values for the first customer duplicated 10,000
times. This will be followed by a similar arrangement for the second customer and their orders.
Error Messaging
Many of Oracles error messages do not provide clear descriptions of the problems being encountered. If
your application will run against both Progress and Oracle RDBMSs, you may want to consider handling
error messages through Progress to provide consistent behavior across both Progress and Oracle databases.
December, 1998
Page 16
INDEXED-REPOSITION Support
The INDEXED-REPOSITION option of the OPEN QUERY statement is only supported by Version 9 (and
above) of the Progress Oracle DataServer. In order for applications accessing an Oracle database to use this
functionality, the query must be defined as SCROLLING, and the table must support the ROWID function.
The INDEXED-REPOSITION phrase is not supported on a view that does not have a selectable ROWID.
Refer to Section 5.7 for more information on using ROWIDs with the Progress Oracle DataServer.
December, 1998
Page 17
Deployment Considerations
Once an application has been created with the Progress Oracle DataServer, there are several deployment
factors that can affect the application's performance and the DataServer's administration. The following
sections discuss these different options and how they influence the application execution environment.
Schema Holders
The schema holder contains information about the data definitions of an Oracle database. This information
includes a description of Oracles structure, the tables, the fields within the tables, and the indexes. The
schema holder contains no user-application data. The Progress Oracle DataServer accesses the schema
holder only when it compiles procedures and at the beginning of a run-time session when loading data
definitions into memory.
As a schema holder is normally run in read-only mode, concurrent access to it by multiple users is not
necessary. The schema holder may also be able to store Progress objects required by applications. For
example, the RBREPORT table accessed by the Progress Report Builder could be stored within the schema
holder, without requiring a separate database connection. (In this instance, however, the schema holder
cannot be connected to in read-only mode.)
For performance reasons, schema holders are best placed locally on the client rather than centrally on the
server (although this difference is much less noticeable when using a fast Ethernet connection as opposed
to 10BaseT configuration).
If a schema holder is desired on a server (for maintenance reasons), it is possible to use the cache database
connection parameter to keep a cached copy of the schema holder on the clients local disk, for faster
connection times. Refer to the Progress System Administration Guide for further details on the cache
parameter.
Page 18
can be applied directly to the existing schema holder. This will allow all formatting information previously
applied to the schema holder to be retained for unaffected objects.
name
(char)
Lift Line Skiing
Sails Afloat
.
.
credit_limit
(decimal)
5,000.00
2,300.00
.
.
sales_rep
(char)
BBB
ARP
.
.
If we create a view (called, for example, v_customer), based on the above customer table, and defined as
the following:
cust_num
(integer)
name
(char)
credit_limit
(decimal)
sales_rep
(char)
our application can now access the data through this view as though it were the original table (which,
essentially, it is). To mask the differences in object naming (the tables name is customer, and the view,
v_customer), we can change the name of the view in the Progress schema holder to customer. The mapping
to the view remains the same, and our application will not need to be changed.
What happens when a third-party application requires a change to the structure of our base customer table?
The answer would depend on the types of changes occurring. The following chart specifies the types of
changes possible on a table structure, and whether or not the application needs recompilation under those
circumstances.
December, 1998
Page 19
Change Description
Adding a column
Adding a column
Dropping a column
Dropping a column
Adding an index
Adding an index
Dropping an index
Dropping an index
Referenced in
View?
No
Yes
No
Yes
No
Yes
No
Yes
Recompilation
Needed?
No
Yes
No
Yes
No
No
No
No
Creating a view does not affect indexing and query resolution. Indexes behave just as they would if you
were accessing the table directly.
Please note that if a column is added to the underlying table (and this column is not reflected in the view),
and you attempt to undo the delete of a row in this view from within a subtransaction, the undo will fail.
The Progress Oracle DataServer will generate an error and rollback the entire transaction.
Refer to the Progress Oracle DataServer Guide for more details on using Oracle views.
Startup Parameters
You should be aware of, and test your applications with, the DataServer (-Dsrv) connection parameter and
its various options. The following options are available for use with the Progress Oracle DataServer:
qt_bind_where / qt_no_bind_where
Specifies whether the DataServer uses Oracle bind variables for values in WHERE clauses.
qt_cache_size
Specifies the size of the cache (in bytes or records) for information used by lookahead or
standard cursors.
qt_debug / qt_no_debug
Specifies whether the DataServer should print debugging information that it generates for the
query to the dataserv.lg file.
qt_lookahead / qt_no_lookahead
Specifies whether the DataServer uses lookahead or standard cursors.
optimistic
Specifies whether the DataServer is to use optimistic locking techniques as the default when
locking records.
skip-schema-check
Specifies the DataServer is to bypass verifying schema definitions match between Oracle
database and the schema holder.
Refer to the Progress Oracle DataServer Guide for more details on these parameters.
December, 1998
Page 20
fields with a common naming convention. Having many Oracle databases requires extra processing
resources, as well as the use of SQL*Net or Net8 for connectivity.
December, 1998
Page 21
Query/Browse Performance
The DEFINE BROWSE statement relies on a unique record identifier for forward and backward scrolling,
hence a valid ROWID or RECID should be made available for that table.
December, 1998
Page 22
Debug SQL
This option prints out the SQL code that the DataServer executes against the Oracle DBMS.
For example, the following 4GL code:
FIND state "NH" NO-ERROR.
FOR EACH customer FIELDS (name) NO-LOCK,
EACH order fields () OF customer NO-LOCK:
END.
Debug Extended
This option prints out additional information to the DEBUG SQL option, such as the execution
of cursors, and array processing statistics.
The following 4GL program (as above):
FIND state "NH" NO-ERROR.
FOR EACH customer FIELDS (name) NO-LOCK,
EACH order fields () OF customer NO-LOCK:
END.
December, 1998
Page 23
Debug Cursor
This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG 18835
with the Version 8.3 Progress Oracle DataServer only) prints out the SQL generated by the
DataServer, along with detailed information about cursor usage (such as opening and closing
of cursors).
The following 4GL program (as above):
FIND state "NH" NO-ERROR.
FOR EACH customer FIELDS (name) NO-LOCK,
EACH order fields () OF customer NO-LOCK:
END.
December, 1998
Page 24
06:41:47
06:41:47
06:41:47
06:41:47
06:41:47
06:41:47
06:41:47
06:41:47
06:41:47
06:41:47
Cursor
OCI call
OCI call
OCI call
OCI call
OCI call
OCI call
OCI call
OCI call
OCI call
Debug Databind
This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG 1029
with the Version 8.3 Progress Oracle DataServer only) prints out the SQL generated by the
DataServer, along with information about OCI bind variables and parameters passed to Oracle.
The following 4GL program (as above):
FIND state "NH" NO-ERROR.
FOR EACH customer FIELDS (name) NO-LOCK,
EACH order fields () OF customer NO-LOCK:
END.
December, 1998
Page 25
Debug Performance
This option (available with theVersion 9 Progress Oracle DataServer, and as DEBUG 55775
with the Version 8 Progress Oracle DataServer only) prints out the SQL generated by the
DataServer, along with information about cursor usage (such as opening and closing of
cursors), and timings (in mircoseconds) for Oracle SQL execution.
The following 4GL program (as above):
FIND state "NH" NO-ERROR.
FOR EACH customer FIELDS (name) NO-LOCK,
EACH order fields () OF customer NO-LOCK:
END.
December, 1998
Page 26
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
06:41:56
<14>
<14>
<14>
<14>
<14>
<14>
<14>
oparse: 1
oexec : 0
oexfet: 1
ofetch: 0
ofen : 0
obnd* : 1
odefin: 1
(2262 us)
(0 us)
(5889 us)
(0 us)
(0 us)
(927 us)
(769 us)
Debug Summary
This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG
1073797455 with the Version Progress Oracle DataServer only) gives information on cursors
and timing in summary form as a Progress data (.d) file.
Debug Verbose
This option (available with the Version 9 Progress Oracle DataServer, and as DEBUG 122879
with the Version 8.3 Progress Oracle DataServer only) prints out the SQL generated by the
DataServer, array processing statistics, information about cursor usage (such as opening and
closing of cursors), along with information about OCI bind variables and parameters passed to
Oracle, and timings (in mircoseconds) for Oracle SQL execution.
The following 4GL program (as above):
FIND state "NH" NO-ERROR.
FOR EACH customer FIELDS (name) NO-LOCK,
EACH order fields () OF customer NO-LOCK:
END.
December, 1998
<0> orgetnext
<0> new 0x0
OCI call oopen <17> cc = 1
OCI retr oopen <17> rc = 0 (1938 us)
<17> Calling idbuf_init from cursor_start
<17> new 0x0
<17> cursor_start
<17> new 0x2
Query flags <17> table 0:
WHERE COMPAT
HAS_RID IDXHINT
Query flag2 <17> table 0:
SLO_CSR
IGN_FL BIG_RNF
Page 27
December, 1998
Page 28
December, 1998
Page 29
Appendix A
Sample 4GL Program To Calculate The Number Of Fields Required For A Progress Table in an
Oracle Database
Progress and WebSpeeed are registered trademarks of Progress Software Corporation. Progress AppServer is a trademark of Progress Software
Corporation. Oracle is a registered trademark of Oracle Corporation. All other trademarks and registered trademarks, marked and not marked, are the
property of their respective owners.
Copyright 1998 Progress Software Corporation
All rights reserved.
December, 1998
Page 30