REIMERS CONSULT Company Logo

REIMERS CONSULT GmbH

Home Feedback Contents

RC.Sql Details

HOME
Up

RC.Sql Download

RC.Sql Product Logo medium

Database Access Library


Features of RC.Sql in Detail

Maintainability
From the beginning, when expanding the system (e.g. new tables, columns, etc.), many errors are excluded. With unique column names, leaving out table names as a column prefix is an error source in statements being based on strings. When expanding the database and from that on the names are not unique anymore, an earlier written program without prefixes has to be adapted costly. This is not necessary when using RC.Sql. Every object (where as well the columns belong to) being produced from it contains the table names.
See the following example to illustrate this essential aspect of RC.Sql:
A commercial enterprise uses a customer and a distributional management system. One table contains the customers. Another table contains the goods being delivered to these customers. The following SQL request is conceivable:

'List all goods being delivered to national customers'
The attribute identifying a national customer can be supported by a method (knowing the customer table) from the customer address.
Now the customer base will be extended. The method to define the country from the address is inefficient. It will be decided, that a new table containing the customer's country has to be created.
Again, the main package asks the customer method providing the appropriate SQL string. But now, not even the customer method as well as any other routines have to be changed, because they do not know the new table, but for the creation of the string statement it is important.
RC.Sql would have limited this problem to the customer method only. For the total rest of the application the created statement object would have all the necessary information. No further modifications have to be performed by the programmer.

Investment Protection
The database provider in an RC.Sql application is minor. Already existing class RcsqlDatabase implementations are included for the database types MS Access, SQL Server, DB2 and Sybase. For additional database provider the class RcsqlDatabase for direct driver access or RcsqlOdbcDatabase for object oriented driver access has to be derived. Database specific characteristics must be implemented there. If there is no variance to common ODBC specifications, the class RcsqlOdbcDatabase can be used without detour.
The various characteristics of the different providers are implemented in the classes already done. An additional distinction between e.g. Sybase ASA and IBM DB2 UDB is not necessary.
After initializing the appropriated RcsqlDatabase instance including the log-on string, etc., a program source code is identically regarding equal database- and table names of different providers. A programmer will use the same code for all (table identical in names and contents must exist in the different databases).
For the user-data stored within the database receives a much higher transparency. The programmer doesn't care about specific syntax rules of single providers or alike. The request implementation has to be performed in the same manner forever. The view onto the data is always as usual.

Object Oriented Statements
The crucial aspect of this library is the fact, that a statement object will be combined out of other objects. For example, a select-statement consists of one Select-, one From- and one Where-clause, among others. Each part is built up from objects. When executing the statement it will be parsed into a SQL statement by elements. The database specific syntax is user independent. It is defined in the database class and in RcsqlSyntax.
By this an identical access is possible to all database types. With no use of data source specific functions, a program may be employed for any optional database type without changes.

Object Oriented Clauses
An additional advantage from object composition lies in the fact that the user doesn't have to create the From-clause when building a statement. The column objects within the other clauses contain references to their tables. These are automatically included in the From-clause. The advantage, when using dialog applications, is, that a selection within a window doesn't need to be followed by the creation of a complete statement.

Reusability of Statement Elements
Reusability of statement elements is given with the composition of each element from objects. A part of it not needed any more can easily be deleted or replaced using a simple method call.

Thread Safe
Atomic actions cannot be interrupted by another thread. E.g. one thread changes the Where-clause of a statement and at the same time another thread tries to set the Select-clause. Each of them would interrupt the other. Against this the classes and methods of RC.Sql are protected, so no inconsistence of one instance can occur from the view of different threads.

Bound Variables
If a statement with only changing parameters has to be used very often, a complete reconstruction of the SQL string is necessary when using text based SQL statements. RC.Sql supports bound variables. They are inserted into the statement instead of parameter values, provided with values and then the statement will be executed. For following actions only the values of the bound variables are changed and the statement can be executed again. The statement itself remains unchanged and will not be parsed again by the library.