Data Access Library for Eiffel contents structure

RS_CURSOR

This is kind of CURSOR which was designed specailly for traversing recordsets.

Besides of standard features of a cursor for two-way traversable container, the RS_CURSOR class allows to jump at the record specified by its ordinal position or move forward or backward with an arbitrary step. As usual, when cursor runs out of recordset it will be stopped, i.e. its is_finished flag will be TRUE.


RECORD

The features field, field_no and field_at does the same as item, item_no and item_at respectively, but stores the latter fields in the that_field attribute. This is useful in some situations to not search the field twice. For example, if you want to display name from the PEOPLE table only when the value of this field is not Null you can write:

record: RECORD
...

if not record.field ("NAME").is_null then
   display_string (record.that_field)
end

FIELDS   PARAMETERS   TABLES   PROCEDURES   TYPES

The DB_CATALOG class represents the notion of a catalog of database objects or their properties which can be enumerated from the database. There are three important facilities provided by this class:

You have the possibility to obtain the item by its composed name. For example, having a recordset built by the following SQL query:

SELECT authors.au_id, authors.au_lname, titles.*
FROM authors, sales, titles
WHERE ...

you can get the second field of the correspondent RECORD via the field feature with either "au_lname" or "authors.au_lname" or even "pubs.dbo.authors.au_lname".

The structure and properties of the composed name varies from catalog to catalog and depends of its nature and peculiarities attached database. For example, data type has simple name whereas field's composed name can be comprised of field's own name, table's name, table's owner and table's qualifier.

Presence and properties of database objects depend on the type of DBMS. However, there are some common places for all relational databases. First of all, in any RDBMS there are zero or more tables. Each table consists of one or more fields. Each field belongs to some data type defined in this DBMS.

One of the principles of DALE is to concentrate on work with databases whose structure is already defined. However, there are some situations when it is needed to explore which objects does the data source have, to find out properties of those objects and so on. The most burning sample is database browser which should be able to obtain the list of existing tables, find out a list of fields for the chosen table, etc. The following example demonstrates how to deal with TABLES and FIELDS catalogs (it is implied that the connection is already established):

db    : DATABASE
table : DB_TABLE
tables: TABLES
fields: FIELDS
field : FIELD
i     : INTEGER

...

tables := db.tables  -- get list of database tables

from
   i := 1
until
   i > tables.count  -- for all tables in the database
loop
   -- print name of i-th database table:
   io.put_string (tables.item_no (i).name)
   io.put_newline
   i := i + 1
end -- loop

...

table := db.tables.item_no (1)  -- choose the first table and
fields := table.fields          -- get list of its fields

from
   i := 1
until
   i > fields.count  -- for all fields in the table
loop
   -- print name of i-th field:
   io.put_string (fields.item_no (i).name)
   io.put_newline
   i := i + 1
end

Among all DALE's catalogs it seems necessary to distinguish data catalogs, i.e. heirs of the DATA_CATALOG class - FIELDS and PARAMETERS. These classes are designed to store INTEGER, REAL, DOUBLE, STRING, BOOLEAN, CHARACTER, DATETIME or BLOB values in FIELDs. It is because these classes have four additional features: put, put_no, put_list and item_list. The first and second ones allow to put a value under a specified symbolic name or an ordinal position respectively. The last two allow to manipulate with arrays of values. For example, if your query has two parameters: INTEGER num_points and BOOLEAN should_mix you can assign 100 and TRUE values by one of the following ways:

A. query.parameters.put (100, "num_points")
   query.parameters.put (TRUE, "should_mix")

B. query.parameters.put_no (TRUE, 2)
   query.parameters.put_no (100, 1)

C. query.parameters.put_list (<<100, TRUE>>)

Obviously, the last way is preferable if you intend to set all the parameters and you know their order very well.

As it was depicted above, database catalogs such as TABLES, TYPES, PROCEDURES, etc. "knows" how to fill up its contents from database by special queries. As a rule, however, the structure of database is not rapidly changed. DALE 1.5 caches the contents of catalogs on the client's side. For this purpose, the CACHE.DBO directory is created automatically in the path where DALE environment variable points to. This allows client's applications to receive database catalogs structure from server only once. To cause applications to update catalogs after one-shot changes, you can either remove the whole CACHE.DBO directory. You can also cause catalogs to update their contents from server right from applications with the help of refresh feature.


Copyright © Object Tools -- info@object-tools.com
Last updated: 2005/02/02 11:51:24