Since I am not at a level where I can speak authoritatively on this
matter. I will speak in ASSumptions, we all know how dangerous that
can be.
I look at our ORACLE DB that was loaded with the definitions in a
PROGRESS DB. I see all these U## fields for case-insensitve indexes.
First Question again as I asked before. Are the U## fields for the
sake of the PROGRESS dataserver or ORACLE? Internally, only to ORACLE
itself I cannot understand why they are there. It's like redundant
information. Strictly for ORACLE'S use it is information it does NOT
need. However, in conjunction with a Dataserver I understand their
function. PROGRESS NEEDS those fields and indexes, NOT ORACLE.
The PROGRESS DataServer For ORACLE Guide Chap2 on Case-insensitve
indexes under Modifying Tables to Support Case-insensitive Indexes, I
think, should read: "To use case-insensitive indexes [THAT THE
PROGRESS DATASERVER REQUIRES] with an ORACLE database, make the
following changes..."
It seems like a whole lot of overhead that ORACLE does not need to
handle: triggers to set up to add, update, or delete the U## fields
when ever the original field is used; have two fields i.e. U##emp-id
and emp-id for each field if it is used as a component of an index;
extra indexes, one for PROGRESS and one for a java GUI client let's
say; etc.
My big ASSumption is this then: suppose I have a nice clean ORACLE
database that has all the tables, fields, and indexes I need; that is,
nothing that even hints that PROGRESS exists in this known universe.
Suddenly PROGRESS and 4GL are born unto this universe. I see it, I
like it, I want to use it... against my ORACLE DB. Based on that, can
I not create a schema-image of that ORACLE DB that I can then place in
the schema Holder that would then be used by the Dataserver?
The schema holder contains information about the data definitions for
the ORACLE database, now the schema-image has all the information that
PROGRESS cares about. The ORACLE DB does not have all that extra
stuff to load it down.
A java-client accessing the ORACLE db, let us say, no longer has to be
bogged down even more or "wonder" what all these U## fields mean, just
the 4GL via the dataserver schema holder(schema-image) needs to be
concerned with them.
I hope I have made sense and have not been excessively didactic.
Larry
TIA
matter. I will speak in ASSumptions, we all know how dangerous that
can be.
I look at our ORACLE DB that was loaded with the definitions in a
PROGRESS DB. I see all these U## fields for case-insensitve indexes.
First Question again as I asked before. Are the U## fields for the
sake of the PROGRESS dataserver or ORACLE? Internally, only to ORACLE
itself I cannot understand why they are there. It's like redundant
information. Strictly for ORACLE'S use it is information it does NOT
need. However, in conjunction with a Dataserver I understand their
function. PROGRESS NEEDS those fields and indexes, NOT ORACLE.
The PROGRESS DataServer For ORACLE Guide Chap2 on Case-insensitve
indexes under Modifying Tables to Support Case-insensitive Indexes, I
think, should read: "To use case-insensitive indexes [THAT THE
PROGRESS DATASERVER REQUIRES] with an ORACLE database, make the
following changes..."
It seems like a whole lot of overhead that ORACLE does not need to
handle: triggers to set up to add, update, or delete the U## fields
when ever the original field is used; have two fields i.e. U##emp-id
and emp-id for each field if it is used as a component of an index;
extra indexes, one for PROGRESS and one for a java GUI client let's
say; etc.
My big ASSumption is this then: suppose I have a nice clean ORACLE
database that has all the tables, fields, and indexes I need; that is,
nothing that even hints that PROGRESS exists in this known universe.
Suddenly PROGRESS and 4GL are born unto this universe. I see it, I
like it, I want to use it... against my ORACLE DB. Based on that, can
I not create a schema-image of that ORACLE DB that I can then place in
the schema Holder that would then be used by the Dataserver?
The schema holder contains information about the data definitions for
the ORACLE database, now the schema-image has all the information that
PROGRESS cares about. The ORACLE DB does not have all that extra
stuff to load it down.
A java-client accessing the ORACLE db, let us say, no longer has to be
bogged down even more or "wonder" what all these U## fields mean, just
the 4GL via the dataserver schema holder(schema-image) needs to be
concerned with them.
I hope I have made sense and have not been excessively didactic.
Larry
TIA