HP3000-L Archives

March 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Dirickson Robert S (Steve) KPWA" <[log in to unmask]>
Reply To:
Dirickson Robert S (Steve) KPWA
Date:
Mon, 8 Mar 1999 14:33:29 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
> In our Y2k conversion, we are converting one database at a time and
> installing the updated apps as we go.  In doing this, we have run into
> situations where the same date field is in two different
> databases being
> referenced by the same program.  We are converting one of the
> databases, but
> not the other.

Unless you have no other choice, don't do that.

> Does anyone know of a way of having the same
> field name so I
> can reference it as an 8 digit field in one database and a 6
> digit field in
> the second database?  I have tried using the aliases in the
> file description
> in Dictionary 3000.  I know that the dictionary utility to
> create Image
> schemas uses the alias from the file description for the
> field name in the
> schema.  I tried doing this with the program.  I created an 8
> digit field in
> the dictionary.  In the file description for the 8 digit date
> data set, I
> used this field with an alias that was the actual field name in the
> database.  In the program, I used my new name for the field.
> The program
> gave me an invalid list error.  So I know that Transact does
> not convert the
> field name in the program to the alias name when it goes to
> retrieve the
> data.  Is this possible?  Or is there another way of
> accomplishing this
> task?

You have to override the dictionary definition of the items in the programs
that reference the unmodified database. I.e., DEFINE(ITEM) the field as an
X(6) in those programs. However
 1) This is a good way to cause problems later, when you get around to
converting the other database, and forget to take out the local-define
overrides.
 2) It may cause problems with the LIST(AUTO) SETNAME construct; I've never
tried it (and don't want to!), so I don't know if a local DEFINE will
override a dictionary definition for a LIST(AUTO) declaration.
 3) It won't work for programs that reference both modified and unmodified
databases.

Overall, converting some-but-not-all databases that use the same item is a
really good way to introduce defects; avoid it if at all possible.

Steve

ATOM RSS1 RSS2