Re: Another multivalue synonym question
- From: "Mark Brown" <mbrown@xxxxxxxxxxxxx>
- Date: Sun, 06 Aug 2006 11:16:43 GMT
The only way is to write a PB subroutine and format the data exactly the
column width and let the data wrap.
The reason is the reason Pick isn't a relational database. You use a single
key to fetch the data for a single "cell", but the data comes back
multivalued. Since it wasn't multivalued to start with the AQL processor
only processes the "field" once. As you point out, the system changes the
value marks to spaces. Since there's a space in the data, the d2/
conversion fails and the data is not formatted at all.
The whole purpose of the translate from day one was to return a single
value. The purpose was to support a many-to-one relationship to save space.
Why store "Philadelphia, PA" over and over when you can just store "19134".
When AQL starts, it sets up processing "cells" for lack of a better term.
Each cell knows if it's single valued or multivalued and the system keeps
track of which value it's processing so it can keep them lined up in a
report. The word translate more correctly means change this to that, not
change this into those.
Sometimes, these kinds of shortcomings can be overcome by looking at the
problem from the other side. Instead of reporting the "header" file and
pulling multi-valued data from a "detail" file, try reporting the detail
file with translates back to the single valued entities in the header file.
But to answer your question, in D3 use something like this:
001 a
002 0
003 SO.DT
004
005
006
007 call format.multi.date
008 tipl;x;;1
009 L
010 9 (allow for space to 'wrap')
subroutine format.multi.date(fld)
convert ' ' to @am in fld ;* make into dynamic array
for i = 1 to dcount(fld,@am) ;* for each value
fld<i> = oconv(fld<i>,'d2/') ;* format date 8 bytes wide
next i
convert @am to space(1) in fld ;* chnge @am to space
return
Mark Brown
<johnmarshall@xxxxxxxxxx> wrote in message
news:1154859402.056922.35610@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Folks
One thing that I've accepted, but that has bugged since the first time
I was introduced to Pick over 15 years ago is what happens when you do
a synonym for a multivalued field, and why the format gets all messed
up in the translate.
Simple example. Lets say in the requirements file (IPL) I have have a
record with a key of part.nbr and a multivalued field of sales order
dates (fieldname SO.DT)
I have the dictionary item for SO.DT in the IPL file
SO.DT
001 A
002 1
003
004 C;2;3
005
006
007 D2/
008
009 R
010 8
and some data:
ipl....... so.dt...
svxmc 20/08/06
30/08/06
20/09/06
If I do a synonym for the IM file which has the same key (part nbr)
SO.DT
001 S
002 0
003 SO.DT
004
005
006
007 D2/
008 TIPL;X;;1
009 R
010 8
The SO.DT data when displayed from the synonym in the IM file is all
messed up, with the 3 date values in internal date format and partially
overwriting the record ID when they display.
:LIST IM SVXMC SO.DT
Page 1 IM
IM........ SO.DT...
SV14112 14122 14143
[405] 1 items listed out of 1 items.
:
Why is this ? Why can't the multivalued data behave nicely when it is
displayed from another file by way of a dictionary synonym? It seems
like the translation process strips out the value marks and replaces
them with blanks.
Any way to get the synonym to display the data nicely?
regards
John Marshall
Christchurch NZ
.
- References:
- Another multivalue synonym question
- From: johnmarshall@xxxxxxxxxx
- Another multivalue synonym question
- Prev by Date: Another multivalue synonym question
- Next by Date: Re: D3 Indices
- Previous by thread: Another multivalue synonym question
- Next by thread: Re: Another multivalue synonym question
- Index(es):
Relevant Pages
|
