??
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 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 typ
PROTECTED] 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 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
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 di
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 forever
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
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 "D"irect fields first then use these fields to build
BH> virtual attribut
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 suggest
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 s
@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 "D"irect fields first then use these fields to build
virtual
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
Personally, I've never used either methods. Here is how I would do the
I-descriptor:
001 I
002 IF @RECORD<12> = "" THEN OCONV(@RECORD<2>,"D4-") ELSE "*VOIDED*"
Gordon J. Glorfield
Sr. Applications Developer
MAMSI (A UnitedHealth Company)
301-360-8839
[EMAIL PROTECTED] wrote on 01/27/2006 03:2
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 "D"irect fields first then use these fields to build
virtual attributes (I-Descriptors) or should one use the direct field
references, "EXTRACT
14 matches
Mail list logo