I have found that deletes are the hardest on index updating, slower than
inserts. If you can, I'd specifically disable the delete from the SO file to
see what change that makes.
Cheers
Stuart
-Original Message-
Basically what happens with the code that does the archiving is it reads the
UD does indeed have NO.NULLS
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wols Lists
Sent: Friday, September 10, 2010 10:00 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Slow READ/WRITE with indexes {Unclas
On 09/09/10 21:29, HENDERSON MIKE, MR wrote:
> Ryan,
>
> You said you had indexes like "'ORDER.DATE', 'COUNTRY', 'MEMBER ID'". If
> those are really the full index data items, you could have thousands,
> tens of thousands, or even hundreds of thousands, of records with the
> identical index data i
An interesting point about Windows 2008 R2 (it's only 64 bit) is the
replacement backup utility cannot both save from a particular drive and
store the backup to the same drive. So, if I were crazy enough to build
a server with just a "C:" drive I would have to set the target for the
backup fi
Unfortunately, I haven't had a chance to play with it. It just looked like
it treated C:\ like XP treats c:\windows\system and warns you away from it.
I was wondering if it would prevent you from creating directories as well as
files.
I would have rather they fixed all of the tools to work with sp
Make sure you do some testing first. Under UniData I found that disabling
the index made things much worse. It created a log file and put a copy of
each record (appears to be the entire record - and not "optimized" for just
the required index info) into it. The bad part was we were building a
repor
Ryan,
You said you had indexes like "'ORDER.DATE', 'COUNTRY', 'MEMBER ID'". If
those are really the full index data items, you could have thousands,
tens of thousands, or even hundreds of thousands, of records with the
identical index data item value in the SOH file. If that's the case,
updates (i
The indexes have been in place for some time now (1+ years)
I'm guessing 10k to 15k new records per day is fairly high volume (this does
not include changes to existing records).
bradley.schrag wrote:
>
> How long have these indexes been in place? If they're new, that's one
> thing. If they'v
I'm trying this now, thanks.
Larry Hiscock wrote:
>
> Are any of your indices based on virtual fields? I haven't worked with UV
> in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX
> commands. If UV also has them, you could disable the indexes prior to the
> archival and
Colin:
I wonder if Windows 7 complains about any writes to the "C:\" drive.
This would be a good thing, but still, some applications install into
"C:\Program Files (x86)", so that directory must allow writes along with
"C:\ProgramData" (notice how they seem to have removed their heads from
The pipe is different. I use it to send output as input to other commands:
!LISTUSER | MORE or
!LISTUSER | FIND "COLIN" /I
But then I've only been really using DOS since 3.11
I've noticed Win 7 hides the root of C:, but I didn't realize that it
wouldn't let you create a file.
Colin
---
what sofware package are you running there at usbank ?
--- On Thu, 9/9/10, bradley.sch...@usbank.com wrote:
From: bradley.sch...@usbank.com
Subject: Re: [U2] Slow READ/WRITE with indexes
To: "U2 Users List"
Date: Thursday, September 9, 2010, 2:39 PM
How long have these indexes been in place
How long have these indexes been in place? If they're new, that's one
thing. If they've been in place for a while and this is a change in
behavior we may need to look in different areas. FYI, on ud I've had
performance issues when going above five indexes on a given file when I
have a high volu
I've been using DOS since 1.0 - forgot all about pipe didn't it
used to be | ?
btw, even though I'm the admin on my laptop, it will not allow me to
even use notepad to save to c:\buddy.txt
Must be a new windows 7 thing.
On 9/9/2010 10:50 AM, Colin Alfke wrote:
If you had the proper
If you had the proper permissions you would have had a buddy.txt file with:
ECHO is on.
in the file. The '>' redirects the output to the file indicated (creates it
if it doesn't exist or overwrites it if it does). I use it to create a log
from a batch file:
Date /t > batchfile.log
Time /t >> batchf
Are any of your indices based on virtual fields? I haven't worked with UV
in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX
commands. If UV also has them, you could disable the indexes prior to the
archival and re-enable and update them at the end. I'm not sure if it would
Use
echo .
to get just a carriage return into the file. Note that you don't have
permissions to write the file, therefore any attempt to create it from BASIC
will also fail.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Be
How does this create a file? I've always code similar to the method
David Green showed, since that works on all pick flavors instead of
having to change my code every time I move to a different system.
C:\Users\AllenElwood>help echo
Displays messages, or turns command-echoing on or off.
I am hoping I can find some help here. I am running into a serious
performance issue with indexes on our UV system (UV 10.2, on AIX).
An example of this is our sales order files, SO (current/active) and SOH
(history) files. We archive sales orders from SO to SOH on a daily basis,
this is moving
OPENSEQ PATH TO SEQFILE THEN
WEOFSEQ SEQFILE ON ERROR
ABORTM "WEOFSEQ FAILED!"
END
END ELSE
* instead of CREATE statement (on Windows)
PCPERFORM "echo>":PATH
OPENSEQ PATH TO SEQFILE ELSE
ABORTM "OPENSEQ FAILED!"
END
END
___
U2-Users
Al;
If you don't want to create the extra VOC entry you can put the entire path
in the OPENSEQ statement:
OPENSEQ 'C:\OUTPUT\APCHECKS999' TO OUTFILE THEN
Or
FPATH = 'C:\OUTPUT\'
FNAME = 'APCHECKS'
OPENSEQ FPATH:FNAME TO OUTFILE THEN
I just find the VOC method easier as I have a lot of prog
because CREATE doesn't exist in Unidata, at least not at my release.
On 9/9/2010 9:05 AM, Rex Gozar wrote:
Al,
Look at the CREATE statement in your documentation. Works for both
Windows and *nix. Frankly, I'm amazed how complicated people are
making this.
OPENSEQ PATH TO SEQFILE THEN
Al,
Look at the CREATE statement in your documentation. Works for both
Windows and *nix. Frankly, I'm amazed how complicated people are
making this.
OPENSEQ PATH TO SEQFILE THEN
WEOFSEQ SEQFILE ON ERROR
ABORTM "WEOFSEQ FAILED!"
END
END ELSE
CREATE SEQFILE ELSE
ABORTM "OPENS
This is what finally worked. I was hoping to do it w/o having to create
a VOC entry, but that was not to be.
Thank you all for your help.
Al DeWitt
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke
Sent
Here is one approach.
OPEN.DIR.FILE:* Open sequential output file
DIR.FILE = "_PH_"
OPEN DIR.FILE TO F.DIR.FILE THEN
DELETE F.DIR.FILE, OUTPUT.NAME
CLOSE F.DIR.FILE
OPENSEQ DIR.FILE, OUTPUT.NAME TO F.DIR.FILE ELSE
IF STATUS() THEN
ABORT.FLAG = TRUE
MSG = "Can'
Al,
Do the following:
OPENSEQ FNAME TO OUTFILE ELSE NULL
WEOFSEQ OUTFILE ON ERROR STOPM 'FATAL ERROR: - Cannot write to file ':FNAME
Now, you should be able to perform the writes without a problem. By the way,
the ON ERROR clause is optional.
The WEOFSEQ will either create the file,
On 09/09/10 05:57, Colin Alfke wrote:
> Al;
>
> I use the following code:
>
> OPENSEQ 'OUTPUT.FILE', 'APCHECKS' TO OUTFILE THEN
> CRT 'APCHECKS ALREADY EXISTS'
> STOP
> END
NOTE THE DIFFERENT SYNTAX!
Looks like OPENSEQ has multiple syntaxes as everybody else has said
OPENSEQ "os path
27 matches
Mail list logo
