From 088603ee6734772d64885d864b7a27f9aa7a36d2 Mon Sep 17 00:00:00 2001 From: hades Date: Thu, 31 May 2001 13:14:20 +0000 Subject: [PATCH] *** empty log message *** --- allParam/ora/README | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/allParam/ora/README b/allParam/ora/README index 162035f..44075e2 100644 --- 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 -- 2.43.0