A database is a collection of data that you can search through in a systematic way to maintain and retrieve information.
Progress RDBMS is an open, flexible, scalable, and highly available database solution that supports virtually unlimited numbers of users and transactions with minimal administration and maintenance. Although dealing with the RDBMS is mostly a development task, this powerful database engine deserves its own section.
Progress contains the following sections:
- Progress Database Architecture
- Storage Design Overview
- Determining Configuration Variables
- Operating System Resources
- Multi-threaded Architecture
- Multi-tier and Cluster Configurations
- Self-service and Network Clients
- Relative- and Absolute-path Databases
Progress RDBMS is an enterprise level relational database system, which successfully competes with the other popular DB systems, such as Oracle, Sybase, Informix, DB2, MS SQL Server.
Progress is in use by many customers worldwide, and in some countries it takes from 20% to 50% of DB market (such as Holland, Sweden, Australia and, of course, USA). Progress has a full-featured 4GL programming language to work with the data and for the programm logic. The same language is used for the user interface programming (GUI and terminal). When working with the data, much better performance is reached, comparing with SQL access, because the data manipulation is done in some lower level, and with more smooth database access commands. Progress has SQL interface too, but it is somewhat slower, so this is not a main priority of Progress.
One of the great characteristics of the Progress RDBMS is a feature called transaction integrity. Properly employed, it guarantees that a collection of record updates is either committed in its entirety to the database or completely rolled back. This provides application programmers an excellent means of encapsulating changes, and relieves them of the effort of writing data-nursing routines to clean up the nasty messes left over from programs that trip over unexpected conditions that would otherwise contaminate the data. But in the real world where programmers are fallible and perhaps even unaware, it is very easy to write a procedure in which the transaction can 'leak' by rolling back some database changes while committing others.
