Just wanted to report back to the list what we found.
As Stephen O'Neal suggested, indexes appears to have been the problem. We
found that the process we were concerned about was updating an indexed field
that contains 15 values. In fact, the index contained only 37 unique entries.
In the s
Richard and All,
The generic reason that multi-part file is faster than a single file is
the dividing of indexes on large files.
On a Multi-part file, there is one set of indexes files per part. When a
SELECT is invoked, it works on each index for each of the part files, then
joins them toget
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of rbl000
> Sent: Friday, January 19, 2007 1:14 PM
> To: u2-users@listserver.u2ug.org
> Subject: [U2] Single Part vs. Multi part UniVerse Files
[snip]
> Needless to say while the s
[mailto:[EMAIL PROTECTED] On Behalf Of rbl000
Sent: 19 January 2007 21:14
To: u2-users@listserver.u2ug.org
Subject: [U2] Single Part vs. Multi part UniVerse Files
We are a UniVerse shop using rel.10.1.15 on HPUX. We have a particular file
that is quite large and central to many if not most activities.
Most likely your problem lies somewhere hidden within the code.
I encountered a similar problem at a government site, where I was as a
contractor confronted with a batch process, that took 18 hours! to run.
My task was to develop a new program using the same logic for a
calculation. I didn't wan
We are a UniVerse shop using rel.10.1.15 on HPUX. We have a particular file
that is quite large and central to many if not most activities. Unix file size
limitations on older hardware and the OS dictated that this file be created as
a 10 part multipart file. Recently we converted it to a sing
