> 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:
PROTECTED] On Behalf Of Stevenson,
Charles
Sent: Thursday, February 08, 2007 8:36 AM
To: u2-users@listserver.u2ug.org
Subject: RE: Spam:RE: [U2] Index Problem
> From: Brenda Price
> 1. < only necessary to rebuild the index(es) when you
> have a known corruption issue. < Management d
> 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
> From: Brenda Price
> 1. < only necessary to rebuild the index(es) when you
> have a known corruption issue. < Management decision
> from a long time ago and it is our comfort level to continue.
> I agree in principal with not rebuilding, but do not have
> 100% faith in any technology provid
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
2007 10:38 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Index Problem
Last night a process that sleeps until around 2-3 am, then wakes up and
does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR
was locked and failed which stopped all the other indices from building.
So whe
Behalf Of Scott Ballinger
Sent: Tuesday, February 06, 2007 3:59 PM
To: u2-users@listserver.u2ug.org
Subject: Spam:RE: [U2] Index Problem
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
On Behalf Of Brenda Price
Sent: Tuesday, February 06, 2007 10:38 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Index Problem
Last night a process that sleeps until around 2-3 am, then wakes up and
does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR
was locked and failed which s
UniVerse 10.1.12 Reality Linux AS3
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Barry Rogen
Sent: Tuesday, February 06, 2007 1:37 PM
To: u2-users@listserver.u2ug.org
Subject: Spam:RE: [U2] Index Problem
Universe ??Version ??
Barry Rogen
PNY
:[EMAIL PROTECTED] On Behalf Of Brenda Price
Sent: Tuesday, February 06, 2007 1:38 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] Index Problem
Last night a process that sleeps until around 2-3 am, then wakes up and
does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR
was locked and
Last night a process that sleeps until around 2-3 am, then wakes up and
does a BUILD.INDEX CUST.MSTR ALL failed. One of the indices BAD.ADDR
was locked and failed which stopped all the other indices from building.
So when we came in this morning nothing had been done from that point
on.
I've ch
: 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
ECTED]
Sent: Tuesday, November 02, 2004 10:00 PM
To: '[EMAIL PROTECTED]'
Subject: [U2] Index problem
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 s
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
vin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of kafsat taiyus
Sent: Tuesday, November 02, 2004 8:00 PM
To: '[EMAIL PROTECTED]'
Subject: [U2] Index problem
We have one Unidata 5.1 data file with a vi
November 2004 03:00
To: '[EMAIL PROTECTED]'
Subject: [U2] Index problem
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 in
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/
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 are added to
the file Unidata does not
47 matches
Mail list logo
