??
Apologies if I've missunderstood the question:
You need to index on the same name that's You use
in your SELECT's or SELECTINDEXes to have an effect !
If You haven't written them yet use the meaningfull PRODUCT.
-- mats
Arnold Bosch wrote:
I have a question / concern regarding the D and
I would second all the points about maintainability and legibility being
key.
One additional thing I have seen on one site:
Unlike the A/S type dictionaries, there is no standard way of separating
base and synonym dictionaries using D types, which can lead to dictionary
listing that takes
Good idea, but is there any performance penalty to using I-types like that?
-- Louie
On 1/29/06, Brian Leach [EMAIL PROTECTED] wrote:
I would second all the points about maintainability and legibility being
key.
One additional thing I have seen on one site:
Unlike the A/S type
Brian Leach wrote...
Unlike the A/S type dictionaries, there is no standard way of separating
base and synonym dictionaries using D types, which can lead to dictionary
listing that takes forever to plough through to get to the definitions of
later fields, and makes writing automated routines to
] On Behalf Of
Louie Bergsagel
Sent: 29 January 2006 17:33
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] Best practices
Good idea, but is there any performance penalty to using
I-types like that?
-- Louie
On 1/29/06, Brian Leach [EMAIL PROTECTED] wrote:
I would second all
I have a question / concern regarding the D and I types:
If a D type is created (F1 below) and an I type added to the dictionary
referencing this D type directly (PRODUCT below), what is the impact on
indexing?
For example, if an index is created on the D type, will UNIBASIC code using
the I
@listserver.u2ug.org
Subject: [U2] [UD] Best practices
I've been converting dictionaries from a D3 dbms and am wondering what is
considered best practices in virtual attribute design.
Does one build standard Direct fields first then use these fields to build
virtual attributes (I-Descriptors
Reusability Readability are two attributes of good software.
Actually, they are also sub-attributes of MAINTAINBABILITY, which I
consider the most important attribute of good software.
Define once reuse.
What we lack is a good standard way to examine dictionaries and their
related pieces.
A
I would suggest a clearer naming convention for your dictionary items. When
you have DATE as part of your field name, it makes sense that a programmer
would expect a date to be returned.
For instance, DEPDATE (or DEPOSIT.DATE) should be a data type (D), and just
the date of the deposit. I
Bill,
Friday, January 27, 2006, 12:24:47 PM, you wrote:
BH I've been converting dictionaries from a D3 dbms and am wondering what is
BH considered best practices in virtual attribute design.
BH Does one build standard Direct fields first then use these fields to build
BH virtual attributes
My ha'pennorth (trans: two cents)
1) If you are using multi-values or multi-subvalues please use Phrases (PH
items) in your dictionaries. It makes life much easier (and safer) for all.
2) Don't assume the date format on the system the software is installed is
*your* date format - be explicit. I
I've been converting dictionaries from a D3 dbms and am wondering what is
considered best practices in virtual attribute design.
Does one build standard Direct fields first then use these fields to build
virtual attributes (I-Descriptors) or should one use the direct field
references, EXTRACT()
Personally, I've never used either methods. Here is how I would do the
I-descriptor:
001 I
002 IF @RECORD12 = THEN OCONV(@RECORD2,D4-) ELSE *VOIDED*
Gordon J. Glorfield
Sr. Applications Developer
MAMSI (A UnitedHealth Company)
301-360-8839
[EMAIL PROTECTED] wrote on 01/27/2006 03:24:47 PM:
To me, this is an issue of readability and maintainability. If I read
'IF VOID = THEN DEPOSITED ELSE *Voided*', I can make a reasonable
guess at what it is trying to do, without knowing anyghing about the
file structure. If you use numeric references to fields, you will
probably have to do
14 matches
Mail list logo