*** empty log message ***

diff --git a/allParam/ora/README b/allParam/ora/README
index 162035f63e8f2ebb4027566aaa2a61f73464a777..44075e26da7610358297fdb294754c0c08fc0735 100644 (file)
--- a/allParam/ora/README
+++ b/allParam/ora/README
@@ -1,8 +1,8 @@
 Author:  Benjamin Sailer
          TUM/E12
          Benjamin.Sailer@ph.tum.de
-Version: 0.1
-Date:    2000-09-10
+Version: 0.2
+Date:    2001-05-31
 
 liboraParam.a
 =============
@@ -36,22 +36,30 @@ Makefile.
 ----------------------
 
   At runtime you also use hard wired access information and have to have a the
-connection to the database, to. Therein the used parameters are all stored in
-a table (view, to be more precise) that is called DAQ.PARAMS and has the
-attributes NAME, IDX, SEQ_NUM, VALUE (which correspond to name, idx and value
-respectively contain the sorting criterium for any array asked for). Of course,
-this view contains a lookup in various tables that hold only specific data sets
-and to supply these is a vast field not yet made applicable for normal users.
+connection to the database, to. Therein the retrived parameters are all stored
+in two tables (views, to be more precise) called daq.param_int and
+daq.param_string while the parameters stored are given to procedures
+daq.store_param.store_param_int and daq.store_param.store_param_string that
+try to match the insertions to special shapes for special insertion treatment,
+and, if the matching fails, put them into the generic tables daq.store_int
+respectively daq.store_string. Of course, former views contain a lookup in
+various tables that hold only specific data sets and to supply these is a vast
+field not yet made applicable for normal users.
 
 4. Known bugs and further developement perspectives
 ---------------------------------------------------
 
-  The only data yet contained in the database are not very structured. Thus,
-developing power has to be invested largely to work out the different database
-tables and their content rather than looking for bugs (which I have not
-disvovered up to now). Anyhow:
+  As the default requirement that inserted parameters can be retrieved as they
+are from the parameter source could not be matched in the database up to now
+(which is a principle problem of the requirement, I guess), tests that rely
+on this feature (e.g. s_store_existing, i_store_existing) may fail. Anyhow, the
+most urgent thing to improve is the shape of the database itself as well as
+filling the tables with proper values for testing with 'real' data and
+requirements. The least developped feature connected to this library at all
+are proper insert forms to fill the database with the correct information
+without the knowledge of the exact structure of the database at all.
 
-Please send bug reports to
+Please send further bug reports to
 
 Benjamin.Sailer@ph.tum.de