> 1. Indexing a computed value, whose calculation does not depend ENTIRELY
> on the record being written. E.g.:
Or to put it another way..
The items in the record must depend on... "The key, the whole key, and
nothing but the key, so help me Codd.".
---
u2-users mailing list
u2-users@listse
(Disclaimer: It's possible that I'm the last one on the planet to learn
of this.)
Nope... Which doesn't mean you weren't the second to last... :)
Mark
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
x27;s possible that I'm the last one on the planet to learn
of this.)
Perry Taylor
Zirmed, Inc.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stevenson,
Charles
Sent: Thursday, February 08, 2007 12:15 PM
To: u2-users@listserver.u2ug.org
Subject: RE:
> I have not seen a problem since about UV9.6.
4 corrections to my own claim.
There are 3 common sources of index corruption, all user-related:
1. Indexing a computed value, whose calculation does not depend ENTIRELY
on the record being written. E.g.:
- trans(), xlate(), T-correlatives
> I have not seen a problem since about UV9.6.
4 corrections to my own claim.
There are 3 common sources of index corruption, all user-related:
1. Indexing a computed value, whose calculation does not depend ENTIRELY
on the record being written. E.g.:
- trans(), xlate(), T-correlatives
istribution of keys?
Just my $0.02 worth
Mike
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Scott Ballinger
> Sent: Wednesday, 7 February 2007 10:59
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U2] Index Problem
>
[sni
If I remember correctly, and tell me if things have changed, indexed
I-descriptors and correlatives that do translates from other files do
not update indexes. This is one reason for building indexes
periodically.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behal
Hi Brenda,
1. It is probably only necessary to rebuild the index(es) when you have
a known corruption issue. I think all indexed fields (I-type or not) are
(re-)evaluated with every write; U2 indexes are self-updating.
2. If BAD.ADDR is just used to identify bad addresses, consider changing
the I-
Universe ??Version ??
Barry Rogen
PNY Technologies, Inc.
Senior Programmer/Analyst
(973) 515 - 9700 ext 5327
[EMAIL PROTECTED]
-
Far better it is to dare mighty things, to win
glorious triumphs even though checkered by
failure, than to
: RE: [U2] Index problem
Kafsat,
I believe that if you pass the record data into the subroutine as a
parameter using @RECORD instead of re-reading it from the file, then you
will have a better chance of getting the behaviour you want:
V
SUBR("KAFSATS",@ID,@RECORD,OTHERSTUFF)
...
From: Doyen Klein
>I found the manual for uv on IBM site
>(http://publibfi.boulder.ibm.com/epubs/pdf/25119270.pdf)
>Any where I can find ...
>
>1. a more detailed internals description of processor mode and
>dispatch type?
Not that I know of. Just the whole VOC section (chapter 3) in the
System
> Subject: RE: [U2] Index problem
>
> Oops, the chart spilled over to pg 3-16, so I fixed it below.
> cds
>
> -Original Message-
> From: Stevenson, Charles
> Sent: Thursday, November 04, 2004 3:10 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [U2] Inde
[snip]
Would you want to maintain 4 separate multivalued attributes in CUSTOMER
to track all ORDERS, INVOICES, CONTRACTS, SALESMAN, etc. ids?
[snip]
Actually, I would. And I do. (Usually)
That way I can use simple translates from CUSTOMERS to ORDERS, INVOICES,
CONTRACTS, SALESMAN, etc for reportin
e utility subroutine is written, the simplicity at the
higher level is restored.
That's how I see it anyway,
cds
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Ballinger
Sent: Thursday, November 04, 2004 2:18 PM
To: [EMAIL PROTECTED]
Subjec
Oops, the chart spilled over to pg 3-16, so I fixed it below.
cds
-Original Message-
From: Stevenson, Charles
Sent: Thursday, November 04, 2004 3:10 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [U2] Index problem
From: Doyen Klein
>Can someone post or point to the doc which
From: Doyen Klein
>Can someone post or point to the doc which describes all the convoluted
and >obscure things one can do when one changes these letters?
Doyen,
Here's a raw cut&paste from adobe reader from sysdesc.pdf, System
Description, UV10, pg 3-15 :
processor mode is used by the command
ration
Edmonds WA USA
206 713 6006
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stevenson,
Charles
Sent: Thursday, November 04, 2004 12:44 PM
To: [EMAIL PROTECTED]
Subject: RE: [U2] Index problem
[snip]
Then 2 steps at TCL or pararaph:
>SELECT O
?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-u2-
> [EMAIL PROTECTED] On Behalf Of Stevenson, Charles
> Sent: Thursday, November 04, 2004 1:44 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [U2] Index problem
>
> In Universe the VOC V-item for XSELECT points to a catalo
I've been out sick for a month and am jumping into the middle of this
thread.
I gather that someone wants to maintain an index on a TRANS() result,
but is frustrated by UV or UD's failure to maintain the index.
Here is a good workaround using my own verb, XSELECT, first implimented
when we were a
6 PM
To: [EMAIL PROTECTED]
Subject: RE: [U2] Index problem
[snip]
Another work around is to have a trigger on the header file re-file the
detail items that reference it so that the index is properly updated.
I'm not sure if you'll have to "change" the detail item or not for it to
c
It seems like the simple solution (which I've used) is that any fields
you need to index in the header simply get replicated in the detail file
as needed and then index those. This always seems to work correctly and
as expected (at least on universe and d3)
>
> We've run into a similar problem w
[EMAIL PROTECTED] wrote:
> Phil:
>
> What I don't understand about this conversation is why would one expect any
> different functionality from the dbms? This has been, in my experience, the
> way indexes have always been on the mvDbms products; whether they be U2, D3,
> or whatever.
>
> When an
. This might
work and be a more practical solution.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Warren, Phil
> Sent: Wednesday, November 03, 2004 6:25 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [U2] Index proble
"Fred Finken" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Here's an idea that I haven't actually tried, but it sure seems like it
> should work:
>
> You have two related files - say ORDERS and CUSTOMERS. You want any change
> to CUSTOMERS name to be reflected in the ORDERS file'
--
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of kafsat taiyus
Sent: Thursday, 4 November 2004 8:00 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [U2] Index problem
Thank you everybody for all your answers.
I have used debug and stepped though the subroutine. While adding a new
re
LT, REC_ID, REC_DATA, OTHERSTUFF)
...
RETURN
END
Cheers,
Ken
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of kafsat taiyus
> Sent: Thursday, 4 November 2004 11:00 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [U2] Index problem
[EMAIL PROTECTED] wrote:
> We have one Unidata 5.1 data file with a virtual attribute.
> The virtual
> dictionary calls a Unibasic subroutine and returns a single
> value data from
> a multi value attribute from within the same file.
>
> We have an index on the virtual attribute. When new records
t a work around.
Thank you again.
Regards
Kafsat
-Original Message-
From: Alfke, Colin [mailto:[EMAIL PROTECTED]
Sent: Thursday, 4 November 2004 6:06 AM
To: [EMAIL PROTECTED]
Subject: RE: [U2] Index problem
I believe it's even in the documentation that UniData will only update
]
>Sent: Wednesday, November 03, 2004 7:25 AM
>To: '[EMAIL PROTECTED]'
>Subject: RE: [U2] Index problem
>
>
>We've run into a similar problem with virtual attributes that reference
>other files in all versions of UniData through to version
>6.0.8. I wonder
>if
Apologies if this has already been said but I have dived in part way through
this thread.
> The only work around that we've used, is to rebuild the index file daily.
> Perhaps there is a better work around or fix?
There is one and only one rule that determines whether you can build an
index o
We've run into a similar problem with virtual attributes that reference
other files in all versions of UniData through to version 6.0.8. I wonder
if this might be a similar 'anomaly'
For example,
In our case we have 2 order files, named HEADER and DETAIL. A virtual
attribute exists in the DETAI
Wendy Smoak
> You're right-- the problem we see occurs when the value that changed is
> in another _file_ not another field. So a trans that pulls a field from
> another file, for example, won't get updated.
Here's an idea that I haven't actually tried, but it sure seems like it
should work:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Fred Finken
Sent: 03 November 2004 15:59
To: [EMAIL PROTECTED]
Subject: RE: [U2] Index problem
> Logically, if field2 runs a subroutine that looks at field3, and
field3
> gets changed... I don't see how the system can be expec
Fred Finken
> Sounds like you're saying that no virtual indices should work
> (whether or not a subroutine is involved). I can see where a
> virtual referring to another item (in the same file or
> another file) couldn't be expected to stay up-to-date with
> changes, but if the references are t
> Logically, if field2 runs a subroutine that looks at field3, and field3
> gets changed... I don't see how the system can be expected to know that
> the index on field2 needs to be updated.
Whoa...
Sounds like you're saying that no virtual indices should work (whether or not a
subroutine is inv
kafsat taiyus
> We have an index on the virtual attribute. When new records
> are added to
> the file Unidata does not update the index on the virtual attribute.
I don't know if it's fixable, but it's something we're aware of and it's
why we rebuild some indices weekly, and why we run some jobs
You said "when new records are added" and this quite possibly might
hold your solution. Are you sure that the virtual is actually
calculating a value on this new record when that record is saved?
Just a thought, but as another person has mentioned it sounds like a
timing issue.
-Kevin
[EMAIL PROT
Perhaps its to do with the processing order, Unidata might be updating
the index on the previous contents? This would seem to fit in with the
rebuild putting the item into the index.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of kafsat taiyus
Sent: 03
REPOSTED FOR A NON-MEMBER [EMAIL PROTECTED]
Kafsat,
Check that the index is enabled. Perhaps you could post output from
LIST.INDEX.
Cheers,
Ken
>
The information contained in this email is intended only for the person or entity to
which it is addressed. If you a
Kafsat,
Can you post the Dictionary Item and the BASIC code?
- Charles Barouch
[EMAIL PROTECTED]
kafsat taiyus wrote:
We have one Unidata 5.1 data file with a virtual attribute. The virtual
dictionary calls a Unibasic subroutine and returns a single value data from
a multi value attribute
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
41 matches
Mail list logo
