From: Brenda Price
1. snip only necessary to rebuild the index(es) when you
have a known corruption issue. snip 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
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
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. snip only necessary to rebuild the index(es) when you
have a known corruption issue. snip Management decision
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: [U2] Index
snip
(Disclaimer: It's possible that I'm the last one on the planet to learn
of this.)
/snip
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/
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
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
:[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
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
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 stopped all the other
] On 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
: [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
[snip]
OT question for the list: is the practice of rebuilding indexes
(nightly?) common? Why? I use a lot
: 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)
...
SUBROUTINE KAFSATS
override the flavor or something entirely different?
Thanks again for the listing. I
-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-u2-
[EMAIL PROTECTED] On Behalf Of Stevenson, Charles
Sent: Thursday, November 04, 2004 4:17 PM
To: [EMAIL PROTECTED]
Subject: RE: [U2] Index problem
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
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's
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 problem
We've run into a similar problem with virtual attributes
[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 index
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
cause the index to be updated.
[snip
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
?
-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 catalogued basic
program and has a K
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 ORD.HDR WITH CUST.NAME = XYZ ABC etc
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]
Subject: RE: [U2] Index problem
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
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 index
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 virtual attribute
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
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
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 to
: [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 expected to know
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:
, 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 same file.
We have an index
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 on
: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 this might be a similar 'anomaly'
For example,
In our case we have 2 order files
.
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 an
index on the file
[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
are
, 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
Thank you everybody for all your answers.
I
:[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
record the program is reading the new non
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
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
41 matches
Mail list logo
