1. Separate I/O for parameter containers derived from HParCond:

    All parameter containers, which do not use HadAscii, can or could use "HCondParIo" for read and write.

          Bool_t XXX::init(HParIo* inp,Int_t* set) {
        HDetParIo* input=inp->getDetParIo("HCondParIo");
        if (input) return (input->init(this,set));
        return kFALSE;
      }

      Int_t XXX::write(HParIo* output) {
        HDetParIo* out=output->getDetParIo("HCondParIo");
        if (out) return out->write(this);
        return -1;
      }
    This I/O is implemented for Oracle, ROOT and ASCII and automatically created.

  2. Parameter containers, which do not use the detector setup, do not need to specify a detector name (HParSet::detName) any longer.

  3. The storage of large arrays and Objects derived from TObject is now supported in HParCond.
    These parameters are stored in Oracle as binary large objects (BLOBs). The ASCII interface is available for arrays only.

    HParamList contains now a second list for binaries and provides functions to fill the list (for write) and to read from the list (for initialization).

    Write:
        void addBinary(const Text_t*,const UChar_t*,const Int_t);
    void addBinary(const Text_t*,const Short_t*,const Int_t);
    void addBinary(const Text_t*,const Int_t*,const Int_t);
    void addBinary(const Text_t*,const Float_t*,const Int_t);
    void addBinary(const Text_t*,const Double_t*,const Int_t);
    void addBinary(const Text_t*,TObject*);
    Input parameters are the name of the parameter, the pointer to the data element and or arrays also the array size.

    Init:
    Two different kinds of fill-functions exist for fixed and variable array sizes.
        Bool_t fillBinary(const Text_t*,UChar_t*,const Int_t);
    Bool_t fillBinary(const Text_t*,Short_t*,const Int_t);
    Bool_t fillBinary(const Text_t*,Int_t*,const Int_t);
    Bool_t fillBinary(const Text_t*,Float_t*,const Int_t);
    Bool_t fillBinary(const Text_t*,Double_t*,const Int_t);
    Input parameters are the name of the parameter, the pointer to the data element and the size of the array. These functions return an error, when the number of array elements read e.g. from Oracle differs from the array size. Null pointers are not accepted.

    The second kind recreates the array and returns the array size. These functions also accept NULL pointers.
        Int_t fillBinary(const Text_t*,UChar_t*);
    Int_t fillBinary(const Text_t*,Short_t*);
    Int_t fillBinary(const Text_t*,Int_t*);
    Int_t fillBinary(const Text_t*,Float_t*);
    Int_t fillBinary(const Text_t*,Double_t*);
    Classes can be read via
        Int_t fillBinary(const Text_t*,TObject*);
    The object must exist. The function returns the class version of the object read from Oracle. It prints a warning, when the class version differs from the actual one.

    The ASCII files for the arrays look the same as for non-binary data, except for the type names:
        hBin for an array of Short_t
    iBin for an array of Int_t
    fBin for an array of Float_t
    dBin for an array of Double_t

    The code has been committed, but the old code for non_binary data still works.
    The ORACLE WebDB GUI was updated and supports now also binary data. But it is not possible to decode the data in the GUI.
    To be not completely blind regarding the data in the LOAD tables, the Oracle interface for conditions contains a function, which allows to initialize the container with a specified version from the LOAD tables.